[Solved] Looking for something to do (preferably Arch/BIM/IFC)

[David_D]

Hello all. New Zealand just just moved to one month of full quarantine, so I've got nothing but free time, which I'd like to spend working on FreeCAD.

Does anyone have any projects they'd like me to do?

- I've got acceptable python skills, and I'm just getting stuck into c++.
- I think I'd be most productive in a relatively green field project, where a very deep understanding of the existing codebase isn't the most important element. I've tried to work on some bug fixes, but I found my lack of understanding of the codebase really kneecapped me.
- I've never contributed to FreeCAD's source. But I have contributed to the wiki, a docker based build system, and an aborted side project workbench, so I'm looking for a chance to get familiarised with the codebase.
- I'd prefer to work on Arch, IFC or BIM, but no biggie.

[vocx]

...
- I'd prefer to work on Arch, IFC or BIM, but no biggie.

You should post in the Draft, Arch, IFC subforum. Actually not many people care about these workbenches in the general areas, because most people are creating 3D solids for manufacturing or 3D printing. However, the small group of people in the Draft/Arch/IFC section are very passionate about what they do.

Projects, yes, there are plenty of things you could do.
* Unit tests for the Arch workbench. The current unit tests are very simple, and don't test everything. We could use many more unit tests. Take a look at Draft's tests. We need something similar, structured in multiple modules.
* Add docstrings to every function. All functions and classes should have a documentation string so that they can be parsed and documented automatically by Doxygen. This is currently lacking. By adding docstrings you will little by little understand how the code is structured. Again, take a look at Draft, for example, draftutils/utils.py.
* Move the Gui Commands into individual modules. We don't want to have a single file with 5000 lines of code, which is why we must move code to individual modules. This is being done currently in Draft. Before, everything was inside DraftTools.py, and now we are placing pieces of it in separate files in draftguitools/gui_polararray.py, etc.

These tasks won't require you to code much, it will be more like detective work because you need to learn the structure, and understand how everything is connected. Then you can start moving things around. Just moving, splitting big files into smaller files will be beneficial to improve development and maintenance of these codebases.

See a general overview in [Discussion] Splitting Draft tools into their own modules.

[David_D]

Projects, yes, there are plenty of things you could do.
* Unit tests for the Arch workbench. The current unit tests are very simple, and don't test everything. We could use many more unit tests. Take a look at Draft's tests. We need something similar, structured in multiple modules.
* Add docstrings to every function. All functions and classes should have a documentation string so that they can be parsed and documented automatically by Doxygen. This is currently lacking. By adding docstrings you will little by little understand how the code is structured. Again, take a look at Draft, for example, draftutils/utils.py.
* Move the Gui Commands into individual modules. We don't want to have a single file with 5000 lines of code, which is why we must move code to individual modules. This is being done currently in Draft. Before, everything was inside DraftTools.py, and now we are placing pieces of it in separate files in draftguitools/gui_polararray.py, etc.

Absolutely fantastic suggestions, exactly what I was looking for.

I think I'll get cracking on that docstrings suggestion, and see if I can make any headway there.

[vocx]

...
I think I'll get cracking on that docstrings suggestion, and see if I can make any headway there.

We just added Draft and Arch coding conventions which are just essentially PEP8, so you may wish to get familiar with them as well. Improving the coding style everywhere is also very much in our interest.

I really suggest using something like the Python editor Spyder because it has automatic checking of PEP8 style.

Don't forget to read Source code management to learn about Git.