FEM Python coding standard

About the development of the FEM module/workbench.

Moderator: bernd

User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by bernd »

PrzemoF wrote:Internal modules that are not supposed to be used in scripting. It doesn't look nice and I'm not convinced that it's right, but that's the meaning. Probably we are not very consistent with that naming.
Thanks. My first impression is, I really like it. I'm gone open a new thread in this regard as soon as I have finished splitting of FemShellThickness.

related: viewtopic.php?f=18&t=12883&start=30#p104961
User avatar
PrzemoF
Veteran
Posts: 3520
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by PrzemoF »

OK, I added it to the opening post.

Is that type of licence header acceptable [1]?

Code: Select all

#*   Copyright (c) 2015 - FreeCAD Developers                               *
#*   Author: Przemo Firszt <przemo@firszt.eu>                              *
or it should always point to Jürgen as the copyright holder?

[1] https://github.com/FreeCAD/FreeCAD/blob ... ader.py#L2
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by yorik »

PrzemoF wrote:or it should always point to Jürgen as the copyright holder?
No, you own the copyright on the files you created. Ideally each person who contributes code to a file should be added, but in practice nobody does that...

I'm not sure that your version works everywhere (the owner of the copyright is the FreeCAD developers). For ex. debian is very picky about copyright, they often whine when these things are not 100% correct. I don't know if they accept the copyright in that form... This should be checked first
User avatar
PrzemoF
Veteran
Posts: 3520
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by PrzemoF »

This is a very thin legal ice as the problems might show up 10 years down the line (*). I think one of the reasons why linux kernel is not using GPLv3 is that this change would require to get permission of all previous developers which is almost impossible. Keeping licence in one file that covers all files (might not be possible) is much easier to control. Anyway, I'm OK with whatever is agreed by the core devs.

(*) ... when FreeCAD rules the CAD world and some of the developers are retired on some exotic islands without internet access to contact them ;)
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by bernd »

I would vote for the following in FEM:

- all new created code files should have unix line endings
User avatar
PrzemoF
Veteran
Posts: 3520
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by PrzemoF »

I don't mind forcing LF as line end, but I think that there is a silver bullet solution. We need to ask the core devs for help. Some reading [1] from the first answer:
"However, there's a better alternative: Benefit from LF line endings in your Linux workdir, CRLF line endings in your Windows workdir AND LF line endings in your repository.

As you're partially working on Linux and Windows, make sure core.eol is set to native and core.autocrlf is set to true.

Then, replace the content of your .gitattributes file with the following

* text=auto

This will let Git handle the automagic line endings conversion for you, on commits and checkouts. Binary files won't be altered, files detected as being text files will see the line endings converted on the fly."

I'll be testing it in on my repo:

Code: Select all

[przemo@localhost freecad]$ git config --global core.eol true
[przemo@localhost freecad]$ git config --global core.eol native
and "* text=auto" in .gitattributes

[1] http://stackoverflow.com/questions/9976 ... rking-copy
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by bernd »

PrzemoF wrote:I don't mind forcing LF as line end, but I think that there is a silver bullet solution. We need to ask the core devs for help. Some reading [1] from the first answer:
"However, there's a better alternative: Benefit from LF line endings in your Linux workdir, CRLF line endings in your Windows workdir AND LF line endings in your repository.

As you're partially working on Linux and Windows, make sure core.eol is set to native and core.autocrlf is set to true.

Then, replace the content of your .gitattributes file with the following

* text=auto

This will let Git handle the automagic line endings conversion for you, on commits and checkouts. Binary files won't be altered, files detected as being text files will see the line endings converted on the fly."

I'll be testing it in on my repo:

Code: Select all

[przemo@localhost freecad]$ git config --global core.eol true
[przemo@localhost freecad]$ git config --global core.eol native
and "* text=auto" in .gitattributes

[1] http://stackoverflow.com/questions/9976 ... rking-copy
I'm fine with the line endings. If a file has mixed line endings I know how to handle this with git (viewtopic.php?t=11952#p96124). You'll be fine anyway since vi is the only editor I know of who really can handle files with mixed line endings. Big problem with all these autocrlf is, one has to know how to use it. Lots off people do not know. Means we will get into trouble again and again ... There are lots of commits in FreeCAD master changing only a few lines off code in a file but changing line endings off this file too.
User avatar
PrzemoF
Veteran
Posts: 3520
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by PrzemoF »

OK, so " eol=lf" probably is the way to go
"Set to string value "lf"
This setting forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out."

I'm OK (linux + vim, always) with that, but I don't know how it would affect win developers.

[1] https://www.kernel.org/pub/software/scm ... butes.html
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Post by bernd »

PrzemoF wrote:OK, so " eol=lf" probably is the way to go
"Set to string value "lf"
This setting forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out."

I'm OK (linux + vim, always) with that, but I don't know how it would affect win developers.

[1] https://www.kernel.org/pub/software/scm ... butes.html
Problems could happen from Linux to Linux too. Assumed a file has windwos line endings. You add two lines to it. These two lines will have unix line endings because vi can handle mixed line endings. If this file is edited by any editor which can not handle mixed line endings it will save the file using one line ending for all lines. If one does not know git properly the line endings will land in FreeCAD master ...
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Python coding standard

Post by Kunda1 »

I listed FEM files that could use a peak at their documentation (list created from a regex) to meet the standards mentioned in the thread.

https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Post Reply