USER FORUM
(you are viewing a thread; or go back to list of threads)
Source Code Organization (by Marthinwurer)
Hey, I was looking at messing around with editing the codebase, maybe working on an idea for #300/#75 (Git friendly save formats). I was looking at the codebase, and it looks like most of the files are just in the main SRC directory, and there are a lot of classes with no documentation. Are there any plans to move some of the classes (like all the ones in sketch.h) into their own module-like directories and split the classes out and add docs? If not, why?
I'm asking this question from a mainly Java and plain C background. Java mostly enforces this kind of stuff, so I'm used to it, but C++ is different so please tell me if I'm completely wrong.
I wouldn't mind doing this myself; I love tidying up codebases, especially for such useful things like this program looks to be. I'm using CLion on Ubuntu 16.04 for development, so large amounts of refactoring will be easy. This kind of structure looks pretty easy with CMake, see https://stackoverflow.com/ques...ltiple-directories-under-cmake for a straightforward example.
The lack of docs makes it a little hard to figure out exactly how things work, especially as a beginner. I don't really have any constructive criticism here, but I could add in things I figure out as I go so the next guy doesn't have to.
Anyways, this project looks super cool and useful, and I would love to not only use it but make it better.
I'm asking this question from a mainly Java and plain C background. Java mostly enforces this kind of stuff, so I'm used to it, but C++ is different so please tell me if I'm completely wrong.
I wouldn't mind doing this myself; I love tidying up codebases, especially for such useful things like this program looks to be. I'm using CLion on Ubuntu 16.04 for development, so large amounts of refactoring will be easy. This kind of structure looks pretty easy with CMake, see https://stackoverflow.com/ques...ltiple-directories-under-cmake for a straightforward example.
The lack of docs makes it a little hard to figure out exactly how things work, especially as a beginner. I don't really have any constructive criticism here, but I could add in things I figure out as I go so the next guy doesn't have to.
Anyways, this project looks super cool and useful, and I would love to not only use it but make it better.
(no subject) (by EvilSpirit)
I vote "for".
(no subject) (by Marthinwurer)
Update:
I have extracted some of the platform-specific code to its own directory; it builds too, which is nice. All of my changes are up at https://github.com/marthinwurer/solvespace/tree/modulization . I'm currently just trying to get as much as I can out of the main solvespace.h header file.
One issue that I've been ignoring is that the FatalError() function is currently defined differently on different platforms and that's tangled in with the rest of the solvespace.h code and I don't know how to extract it. I've sidestepped the problem by inlining the required code for my platform (linux) and figuring that I'll be able to sort that out later.
As always, feel free to send any constructive criticism my way. It will only make me and the code better.
I have extracted some of the platform-specific code to its own directory; it builds too, which is nice. All of my changes are up at https://github.com/marthinwurer/solvespace/tree/modulization . I'm currently just trying to get as much as I can out of the main solvespace.h header file.
One issue that I've been ignoring is that the FatalError() function is currently defined differently on different platforms and that's tangled in with the rest of the solvespace.h code and I don't know how to extract it. I've sidestepped the problem by inlining the required code for my platform (linux) and figuring that I'll be able to sort that out later.
As always, feel free to send any constructive criticism my way. It will only make me and the code better.
(no subject) (by Marthinwurer)
Most of the header info is out of solvespace.h now. I just got it to build, but there's a lot more work that needs to get done. It's 1:30AM here now so I'm going to sleep now.
(no subject) (by Paul)
I'm a fan of documentation. I started digging in to make variations on extrusions and found the lack of documentation to be a problem. It appears there are redundant data structures, but I think there are good reasons for that. The problem I found was a lack of explanation for how and when things need to by synched up. Reading the code is not enough.
Post a reply to this comment: