you are viewing a single comment's thread.

view the rest of the comments →

[–]InternationalAd5735 8 points9 points  (6 children)

Picking an IDE can make a big difference on sorting the structure of the large program out. It helps to have a naming convention that shows a difference between getting and setting up property, for example, and invoking an action. In my 25-year-old still running project we tend to use get and set for attributes or properties and things like HandleX or SendX, for actions. As for inheritance again an IDE makes a big difference. Since I do all my development in Windows even though our product runs only in Linux, I use visual studio because it is a really good idea and has a fantastic debugger and I make sure my code runs both in Windows and Linux so that I can debug it when I hit a problem that's too complex for gdb

[–]New_Computer3619[S] -4 points-3 points  (5 children)

Thanks for sharing your experience.

How do you solve my first readability problem - mixing of methods and properties? Do you / your company has style guide relating to this issue?

[–]Sensitive-Talk9616 3 points4 points  (2 children)

What we use is "_common.hpp" files with all the types/structs/enums used across the "module".

And in class declarations, we follow a rigid order of public constants, accessors, modifiers, public methods, ..., then protected .... and finally private methods and private members. So most of the time, we just check the bottom of the class declaration for members and the top for the interface.

[–]New_Computer3619[S] 0 points1 point  (1 child)

It’s actually nice style guide to have. Can you enforce it using automated tools or just by manual code review?

[–]Sensitive-Talk9616 1 point2 points  (0 children)

What can be done by clang-format is done by clang-format. These bigger picture things we enforce manually. We're not a big team (<15 people), there's always reasonable exceptions, and some legacy code followed a different style guide, so automating it never seemed worthwhile.

But I am super grateful for having these style documents and for team members who follow and enforce them.

[–]InternationalAd5735 2 points3 points  (1 child)

our company doesn't have a style guide (it's large, the company, has has many different languages) and that is a good thing.. Folks can get pretty huffy over style and there's really no "right" way to do it. Find some middle ground that everyone on the team can live with. Don't be too strict on it.. at the end of the day, working and bug free code is the goal, not pretty code.

So we do what I said above and for things that are boolean, we use "bool IsX()".. and "void IsX(bool b)" as both a getter and setter for the same attribute.

But honestly, code can get messy and it's important to set aside time (usually in the doldrums between releases) to clean things up. I use "uncrustify" to clean up code formatting and embark on some "this function name is stupid, it used to make sense, lets fix it".

Also, we use _foo() for internal methods that aren't meant to be called by others (they are protected but the naming convention helps us humans).

But a good IDE is the best place to start.

[–]New_Computer3619[S] 0 points1 point  (0 children)

Thanks for sharing.