OF Coding Practices ( prev c++ in the core..... )

There has been a lot of discussion about things like namespaces, initialization lists, const correctness, templates etc that has been creeping into the source code formatting thread. So here is a new thread to discuss those things.

Please read first the code style wiki which includes a little on our current perspective on some of these topics:
https://github.com/openframeworks/openFrameworks/wiki/oF-code-style

A little history
Early releases of OF were very non C++ style. We used char * arrays for strings, c arrays instead of vectors and we didn’t include anything from STL. Our coding roots is somewhere between Java, C and C++ ( more on the c side ) with a big dollop of artist thrown in to piss off the computer scientists amongst you :slight_smile: Anyway that is the vein that OF came from, so please be kind when we are a little suspicious of turning OF into a super templated, const correct, api. We never sat through that class and are always a little hesitant to turn OF into something that we don’t completely understand ( except arturo who seems to get everything ).

Having said all that, this is also a process and we are also learning too, so we are all ears and open to the collective wisdom of the OF community. Please share with us your thoughts!

ps: Another thing to consider was that in the past, OF core was very small and it came uncompiled within each example. We wanted people to look at the code and we wanted new comers to C++ to be able to understand it and not be intimidated by it. As things have progressed the core has got a lot bigger and more flexible, the things that make it powerful ( like swappable apis ) have also made it less suitable to be included uncompiled and not so friendly to beginners. There is a strong argument that as a framework it might not be so important for beginners to understand exactly how it works but for beginners to understand how to use it. This would mean pushing the focus to more and better examples and api improvements, but not worrying so much how the OF core is perceived by someone who is not such a strong coder. This choice has been a struggle for us, as intrinsic to OF was the idea that you could easily dig down and see how a line was being drawn or how a calculation was being made. With 007 and the swappable renderer its already a much more involved process to just find out how a line is drawn. But now people can draw lines via GL or to pdf via cairo, so there is of course a tradeoff.

I think if there was a single ideal we have in terms of this subject it would be this:
**“simple to understand for beginners, powerful to use for pros” **.

I like to think we can achieve both of those things.

i completely agree that the OF core no longer needs to be understandable for beginners. it only needs to be understandable for contributers.

the places to focus, in my opinion:

  • standardization: creating a unified load() method is a good example. and ofSerial is ancient.

  • simplification: fewer user-facing methods, generalization of common patterns, reduction of the inheritance hierarchy

  • documentation: lots of work from roxlu and others, but we need something unified that can live both on and offline

  • examples: 007 saw some cleanup thanks to theo, but we need to expand and simplify

anyway, that’s more of a ‘future directions’ list. this thread is about OF coding practices.

[list]

  • initialization lists: yes please. it’s a great way to initialize things. it might be faster in some cases, but my main feeling is just that it’s cleaner.

  • namespaces: yes please. i’m looking forward to a day when OF could look more like cinder or processing depending on whether you say “using namespace of”. i’ve been using namespaces more in my work recently and it’s really refreshing to know everything is divided neatly, and i can use class names like “Camera” without worrying.

  • const correctness: yes please. there are some very subtle details to const correct pointers i don’t completely understand, but i think 98% of what you should be doing with const is obvious after studying it for less than an hour. my argument for const is the same as before: if people want to write code/use libraries that are const correct, it can be hard to use OF at the same time. but if OF is const correct, people have the option.

  • templates: yes please. templated ofColor and ofImage has made my life so much nicer. now there are no ambiguities with ofColor as to whether it refers to 0-255 or 0-1. and ofImage being templated has wrapped up a big reason of why ofxOpenCv existed in the first place. that doesn’t mean everything should templated, i think it’s in a pretty good place at the moment.

[/list]

I agree about standardization. Right now things are quite different as you go class to class and I think the more similar things are, the more intuitive the use of them will be.

Method / function naming comes to mind to. It kills me that ofAngleDifferenceDegrees is not ofGetAngleDifferenceDegrees

If we were to move to initialization lists then it would be a great chance to make sure all member variables are initialized and being used by the class.

The const correctness stuff I think I am more open to now - the stuff you pushed into 007 hasn’t bit me like I expected it to :slight_smile:

I am very curious about the namespace thing. As you remember it was quite a discussion before.
I would love to get a sense of some different ways it could be applied to OF. The thing I am not so keen about it namespaces is, in the most practical way of using it, it becomes quite unclear what something belongs to and whether it is part of OF or some native OS function you are using.

eg: system
and OF::Core::System ( just as an example )

Anyway I think it would be good to look at for sure and think about how it could be applied.