That one asks 'should you have one?' I know you should have one, I want to know what should be in it...
– AShellySep 10 '10 at 19:41

If you can vote and think this is a useful question or it have useful answers below, please vote up. StackExchange sites need votes to build a good community. You can give 30 votes per day, don't waste them. Specially users with high reputation and low counting votes given please read this: meta.programmers.stackexchange.com/questions/393/…
– ManieroOct 5 '10 at 19:29

I disagree to some extent. I have to deal with too much code where the function names are vague, ambiguous, or misleading, and to figure out what the code actually does, you always have to go to that method anyway. Just looking at your second example, it's extremely unclear what the code does. Hopefully you'd use more concrete names in practice.
– JacobNov 13 '10 at 0:04

3

where did "somewhere" and "sort by what" end up?
– user1249Dec 4 '10 at 23:00

I despise this one when I use an API designed this way. It forces me to write tons of import statement boilerplate to use a bunch of classes that are naturally related and search four zillion auto generated documentation files to find what I'm looking for. From an API usability perspective I much prefer coarser grained imports.
– dsimchaSep 27 '10 at 23:09

2

It'll depend on the language but in C# this is definitely the route to go. SRP plus one file per class results in very few 'false positive' merge conflicts if you're working in a team. It also has no impact on the API (that can be simplified with facades for example)
– FinnNkOct 30 '10 at 15:33

@FinnNk: So this rule is about source code control management? Also, what is a facade?
– Robert Harvey♦Nov 13 '10 at 1:30

No, but following SRP means that if two people are working on different things then their code is less likely to result in merge conflicts. The rule has nothing to do with scm but simplified scm is a by-product. The comment about facades was aimed at dsimcha's comment about wanting coarser grained imports for api's. See en.wikipedia.org/wiki/Facade_pattern for definition.
– FinnNkNov 13 '10 at 10:17

Adequate and consistent use of whitespace, both vertical and horizontal, vastly improves the ability of the code to be rapidly skimmed as well as read at a normal pace. I'm not going to argue about tabs versus spaces, as long as their usage is consistent, but proper indentation and judicious use of blank lines and spaces around operators are all absolutely necessary.

Related: keeping line lengths to a reasonable limit such as 80 columns has demonstrable benefits: no weird wrapping on consoles, no need to scroll, and the ability to view multiple files side by side on a wide monitor, not to mention that it tends to help encourage refactoring of deeply-nested code and run-on expressions.

spaces should be favored over tabs at all times for portability, tabs look different from one terminal or editor to another, but spaces are always one character each.
– Jimmy HoffaSep 6 '12 at 2:37

1

@JimmyHoffa: I prefer spaces as well, but I’ll play devil’s advocate and point out that looking different is the point of using tabs—I can (setq tab-width 2) in Emacs and my buddy can set tabstop=4 in Vim and everybody’s happy. It’s akin to the difference between hard and soft wrapping.
– Jon PurdySep 6 '12 at 17:38

1

@JonPurdy: Definitely, though I'd also say that the main time where spaces have an advantage is when lining up parameters with an open paren, which I and many others who use tabs don't do because method name lengths vary, and code indentation levels (imo) shouldn't.
– MagusFeb 27 '14 at 21:44

@Magus: Sure, then again I am allergic to alignment even when using spaces exclusively, because it tends to make for bad diffs and blames, and makes style-preserving automated refactors more difficult.
– Jon PurdyFeb 27 '14 at 21:58

Agreed. It's just the most common argument for spaces. I don't believe in it at all.
– MagusFeb 27 '14 at 22:04

It doesn't matter so much which standards you use for which name types, as long as it's consistent among that type (eg, all constants are capital), consistent within the project, and different from eachother. The benefit here is that I can tell at a glance that _someVar is a private field without having to look it up.

This is by no means a style unique to C#. Most C++, Java, and C programmers have a similar style rule.
– greyfadeSep 10 '10 at 20:52

I'm aware- that's just the language I was using when that standard was imposed on. You are correct that it is appropriate to many languages.
– FishtoasterSep 10 '10 at 21:55

I use camelcase for private variables and single underscore pascal case for members used by properties. Also, since properties are the like a combination of public variable and method they're also pascalcase.
– Evan PlaiceSep 12 '10 at 1:04

2

I agree in general but disagree on the "constants are capital" rule. I think this type of rule evolved from misapplying the C "preprocessor macros are all caps" rule (which makes sense, it's a dangerous construct and all caps makes it stand out). I don't think it adds any value to be able to tell whether a given symbol is constant or not and it conflicts with the other rules: "is this a private or public constant?" naming rules are a good thing, but they should take the language's capabilities into account and not just be dragged from one language to another whether they make sense or not.
– FerruccioOct 7 '10 at 16:18

Reason: When scanning code, Macros stand out from regular functions, and alert you that there may side effects a normal function call would never have, like changing the value of the "input" argument, or having it evaluated 3 times.

@Kryalessa, Hungarian notation statically encodes the type of the variable in the variable name. In a dynamically-typed language, the static type encoding is probably wrong.
– John R. StrohmJun 14 '11 at 17:52

What John R.Strohm said. Also, in dynamically typed languages one usually uses duck typing, where there might not be just a single type to be encoded in a variable name. If you try to encode all the possible types into a variable name, you're likely to end up with something like list_or_set_or_deque_or_string.
– pillmuncherJun 14 '11 at 19:49

so IMyInterface should be banned? and so should _privateVar? (although _ doesn't explicitly say 'private' it is used as a convention nowadays). sometimes these hints are good to have which is exactly what Hungarian was all about. (sure, overuse is very bad, so 'genymdhms' is still not good practice by any means but pXXX (for pointer) is)
– gbjbaanbJul 4 '11 at 16:05

@gbjbaanb: I'd argue that they should both be banned, considering that a decent IDE can color them distinctly. However, in languages like C# and Java, the interface prefix is a standard part of the BCL, so it may as well be followed.
– MagusFeb 27 '14 at 21:50

Formatting - especially Indentation! I'm using Delphi and the first thing to do when I get code not formatted to my usage I reformat it. The built-in formatter in Delphi serves as one of the most used fetaures in these cases.

Preprocessor Macros: Be very cautious with macros. Prefer inline functions, enums, and const variables to macros.

Smart Pointers: If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr.

SQL

Oftimes we would create a widget for a customer and 3 months later we would resell that widget to another customer. Eventually naminging conflicts arose and we had to recode a widget.

For example:Press Release Widget

tblContent

tblCategories

tblImages

Photo Gallery Widget

tblPhotos

tblCategories

If Customer-A already had the press release widget and now wanted the Photo Gallery widget we had a naming conflict with tblCategories. We couldn't just script the Photo Gallery elements and run them against Company-A's database. Argh!

So we we started appending a "widget" references to our SQL elements:

tblPG_Photos

tblPG_Categories

tblPR_Content

tblPR_Categories

tblPR_Images

spPG_Proc1

spPG_Proc2

spPG_Proc3

spPR_Proc1

spPR_Proc2

spPR_Proc3

This kept things nicely bundled and helped us be more profitable in the long run.

Unique naming method, does not matter on the language. For example.. G = Global, L = Local ,P = Parameter. Now when you have a variable like G_strFoo I know that it's definition can be located in my global file. Helps with keeping up with all the variables in my programs.

This is only useful as compensation for bad design. By avoiding globals, and implementing small classes and functions each with a single, well-defined purpose, the scope, type and purpose of a variable will be clear without pseudoHungarian tags.
– Mike SeymourOct 7 '10 at 15:21

I think as far as coding conventions go, the primary thing that contributes to the reliability, maintainability, and readability of code is naming conventions. The rest of the stuff is pretty standard.

There is not one "right" or "wrong" way with naming conventions. The key is consistency. For example, I always use camelCasing for parameters and local variables, I use camelCasing prefixed with an underscore for private / protected field members, and I use PascalCasing for class names, properties, events, functions, etc.

I generally shy away from hungarian notation as well for the sake of readability but I do think that in some scenarios it is helpful (I usually use hungarian notation for GUI types).

One side effect of sticking to conventions is that it is easy to keep track of what type of identifier you are looking at when reading code. For example, I can always rely on the fact that properties utilize PascalCasing while local variables do not, which saves me from having to scan back and find the definition of an identifier when reading code.

Having your team follow the same coding conventions and standards can help make your software more readable and more uniform by keeping things consistent and clean. This facilitates maintainability by allowing members of your team to be able to read and comprehend code written by co-workers more quickly without having to mentally run a background filter to interpret layout and style differences, etc. It also fosters best practices and can contribute to keeping your APIs consistent as well.

If your code is clean, consistent, and easy to read, it becomes more maintainable and less error prone.