This is not an actual forum-supported poll because this isn’t about giving you specific options and then seeing which is most popular, but rather I would like to know how you feel about the following case.
Let’s say you joined a company and they have some coding standards to which you must adhere. Right now I mainly want to know how you feel about their style of braces conflicting with your own, but I generalized the topic so that I could ask my follow-up question as well.
Braces
How do you feel about policies that strictly control how you brace your code?
For example, would you prefer a policy that strictly requires all braces to be on their own line, or a policy that defines only where to put braces when declaring a class or defining a function, but lets you use your own style inside functions (which may well be to put them on their own lines)?
To segway into the next section, how irksome is it to have to conform to using a brace style other than your own?
Does it just bother you but you can get on with it, or does it leave a nasty taste in your mouth and make you disgusted at your own code?
Other
I am largely interested in what things you consider most annoying to change about your own style.
For example, maybe it would annoy you a little to have to prefix a class with “C” if you are not used to doing that, but how annoyed would you be if you could not use “m_” for members of a class?
List, in order from most grating to slightly tolerable, things you would hate to change about your own style if you had joined a company that had a coding standard largely in-conflict with your own.
L. Spiro
Coding-Style Poll
I prefer Allman brace style but to be honest, brace style, indentation, tabs-vs-spaces, etc - I can live with all of those. Worst case is I run the code through a source formatter after checking it out, then again before checking it back in. Takes a couple of seconds, no big deal and definitely not worth getting upset over.
"m_" and "g_", on the other hand, stop me in my tracks. I mean if I was forced to use them, or if I encountered code that used them. It's not grating and it's not annoying, it's that they genuinely stop me in my tracks and impact my productivity that much.
I don't work in an environment where anyone is telling me how my code should look, so I haven't had to play that game. But I can say it does irk me sometimes when reading other coding styles on websites (gamedev, stackoverflow, etc). I can get over it, but it sometimes feels like I have to stare at the code longer. Heck, I think I've been known to reformat other people's code when I post replies.
I like braces being on their own line and to line up vertically with their match. I just find this easier to look at. When it is at the end of the line, it feels like i have to hunt for it.
I used to subscribe to the prefix (C, I, m_), but over the years I just found them annoying. I think as soon as I had a class that started with a C or an I (making a double letter), it just looked weird to me (CClass or IInterface). I will occasionally use an underline suffix when using c# and properties when there is a similarly name variable backing up the property, but I try to avoid it when I can.
I also subscribe to the Pascal (or Upper Camel Case) for naming.
I use Allman style when writing my own code - and when I modify existing code, I use whatever style is already there. Personally it doesn't matter to me as long as it's consistent and not ridiculous (eg. 2 blank lines between 'if' and the brace).
I think the only annoying thing would be if a company code standard demanded rigorous Hungarian type prefixes - the more rigorous and varied, the more annoying.
I think the only annoying thing would be if a company code standard demanded rigorous Hungarian type prefixes - the more rigorous and varied, the more annoying.
The guiding principle is that if you are working on an existing project, you try to follow the style you encounter, so your code doesn't clash. Actually, that is the only principle we follow at work, and it has resulted in a consensus style that we are all familiar with. There are parts of the code that don't exactly conform to it, but we don't get our knickers in a twist about it.
For braces, I like this style:
So, opening brace on the same line after a space, closing brace on its own line, and no need for braces if the block is a single thing that fits in a single line. This is what I am used to, and I like how it's clear enough and doesn't waste too many lines. I examine code in a screen with limited vertical real estate, so line efficiency is somewhat important.
About your second question, I don't think I could live with Hungarian notation or similar conventions to pollute variable names with auxiliary information. A lot of the code at work does the m_ thing for members, and I have learned to live with it, although it seems to me that classes should be small and understandable enough that it should be obvious what's a member and what's not.
I can't think of anything else that would bother me. But I am probably just not thinking about it hard enough. :)
For braces, I like this style:
bool is_prime(unsigned n) {
if (n % 2 == 0)
return n == 2;
for (unsigned k = 3; k * k <= n; k += 2) {
if (n % k == 0)
return false;
}
return true;
}
So, opening brace on the same line after a space, closing brace on its own line, and no need for braces if the block is a single thing that fits in a single line. This is what I am used to, and I like how it's clear enough and doesn't waste too many lines. I examine code in a screen with limited vertical real estate, so line efficiency is somewhat important.
About your second question, I don't think I could live with Hungarian notation or similar conventions to pollute variable names with auxiliary information. A lot of the code at work does the m_ thing for members, and I have learned to live with it, although it seems to me that classes should be small and understandable enough that it should be obvious what's a member and what's not.
I can't think of anything else that would bother me. But I am probably just not thinking about it hard enough. :)
I think every project/codebase should have a defined style all the way through.
I'm just sooo happy I work in C# where there's basically one universally accepted naming convention and one almost universally accepted formatting convention. Sure, there are differences between projects sometimes, but the differences are typically negligible compared to many other languages.
List, in order from most grating to slightly tolerable, things you would hate to change about your own style if you had joined a company that had a coding standard largely in-conflict with your own.
that's easy. its all about keystrokes (data entry speed) and readability. the more unnecessary keystrokes, the more annoying it is. the less readable it is the more annoying it is. typing takes time. deciphering code takes time. time is money. but unlike money, you only have a finite amount of time - don't waste it.
that being said, it sounds like you've been hired to produce code that conforms to certain formats and coding conventions. it would probably be a good idea if you just swallowed the bitter pill and wrote their ugly code for them. and be thankful you can define your own saner conventions for your own projects.
I'm flexible to what is agreed on and what's already there. Different code style doesn't bother me at all, as long as it is consistent. What's annoying is when it is not consistent. What annoys me is like this:
void foo()
{
if (true) { // <-- inconsistent braces.
...
if (false)
do something // <-- no braces gives problem when more than 1 line is needed, and again it's inconsistent.
}
}
Any prefix, as long as they're consistent, I'm on it, even if it's as silly as prefix "S" for struct. I'll be annoyed if suddenly I see struct without "S" when it is already agreed that we should use "S" for naming structs.
Technically, however, "m_" gave me a problem with IDE. If there's an agreement not to use "m_", of course, as I said, I'm okay with it. But technically, in my experience, "m_" for private properties makes things easier on code completion and realizing on private properties on Visual Studio. Same goes to "g_" or "kVarName". Visual Studio's code completion somehow doesn't make a good order on which is private and which is public, which is global and which is related to the class and order things by that.
But in JetBrains WebStorm with code as sick as JavaScript, it can easily and automatically tell me which is private (semantically) or not, which part of the class or not, even with just a "_" prefix.
Author
Opposite.that being said, it sounds like you've been hired to produce code that conforms to certain formats and coding conventions. it would probably be a good idea if you just swallowed the bitter pill and wrote their ugly code for them. and be thankful you can define your own saner conventions for your own projects.
We are defining new standards and I am on the committee.
As for me, one of my policies is that happy coders are more productive coders, and one way to make unhappy coders is to make them use a style they dislike a lot.
A coding-style guideline should not be overly restrictive, especially unnecessarily. But the boundary between consistent coding and “comfortable dissonance” is not an easy line to draw.
This poll is really as straightforward as it sounds—no hidden motives about getting pushed into a style I don’t like etc.
The more topics I know that people consider “personal” the better I can consider where we should give people a “personal comfort” pass weighed against the clarity/consistency of the resulting code base.
L. Spiro
It completely depends on the developers I think... I've worked with devs who I can't understand what's going on until I place in some white space, and I've worked with devs who document everything fine.
The best standard I've used is one where an example of test data for parameters is included in a header for each method that has at least a few returns, so it just "made sense" when jumping into any method.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
