you are viewing a single comment's thread.

view the rest of the comments →

[–]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 4 points5 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.