The Source of Readability

I&#x27;m going to push back somewhat on global variables. I think they can actually be very helpful when you are working in the debugger, particularly with memory dumps. Instead of looking across a bunch of different threads, you can inspect globals directly.<p>In terms of not wasting vertical space, I think you&#x27;ll run into issues since it starts to conflict with readability from familiarity. People aren&#x27;t used to having a bunch of statements on a single line so they may not notice it. There&#x27;s a similar phenomenon with reading research papers where it is very time consuming initially because you may be unfamiliar with the structure, but after a while, you can read them very quickly since you know what to skip over and what to pay close attention to.

I break two of these all the time: minimize vertical space and define variables close to their use.<p>I&#x27;m one of those people that prefer braces on their own mine, even left braces.<p>But it works for me. Empty space actually helps me read my code more easily.<p>Likewise, in C, I define all variables at the top of a scope. This is dangerous in C because of the possibility of uninitialized data, but Clang catches everything. And I prefer it because Clang has a warning to enforce that style so that I can&#x27;t mix styles. Also, using those variables becomes like using type inference in other languages; the first use looks like initialization without the type annotation.<p>Not that the author is wrong, but don&#x27;t feel bad if you depart from this for your own personal stuff. And follow whatever style policy is required by your employer.

To novice, most of these are guidelines, don&#x27;t treat them as rules. If something feels wrong to you, you are free not to follow them. Also almost always follow the conventions of your team&#x2F;project. Nothing is worse than multiple coding styles in a project, unless whole team finds it better and decides to follow it.<p>Clear naming will give you most ROI. When you have confusion follow the simplest path, it is always easier to refactor simple code later.