I had to work on a program recently where the developer's personal convention was that every variable name should be 4 characters long:

var cnam // customer name
var ccrt // customer credit rating
var olnm // order line number
...

Hungarian notation ^[1] always makes me think evil thoughts. I understand the reasoning behind it, but not all who use it do. Even with the proper prefix usage, I still find it baroque.

I did work in a team where every interface's name had to end with "Able" (with a capital "A"). It doesnt sound all that bad : Serializable, Cloneable, ... are perfectly good interfaces names. But all our code is in French. And of course, Able doesnt mean anything in French. We ended up with service contracts called something like TaxRetrievalServiceAble and TaxRetrievalServiceImpl, even worse as it was in French : RecuperationDeTaxesServiceAble et RecuperationDeTaxesServiceImlp.

I really hate the m_ and s_ conventions for member/static variables.

I dislike programmers dropping vowels from variable names. Why type 'txt' when you can type 'text'? I prefer variable names to be more verbose, it can only be helpful.

I have also encountered people who favour single character variable names!!!! The reasoning behind it was that they prefer to fully qualify everything to "make it easier to understand what the variable is", so this guy uses single letter variable names for brevity.

i.e.

Root.Namespace.Namespace2.Namespace3.ClassName a = 
new Root.Namespace.Namespace2.Namespace3.ClassName();

Root.Namespace.Namespace2.Namespace3.ClassName2 b = 
new Root.Namespace.Namespace2.Namespace3.ClassName2();

And then much later in the code you see this...

a.toAssociation(b.toPoint());

This makes me ask myself "what the hell is 'a' and why can I can call 'toAssociation' on it, and what the heck is 'b' and why can I convert it to a point?".

It is seriously not helpful...

I dislike Windows' tendency to typedef pointer-to-X as PX.

This removes the asterisks from the declarations and definitions using this code, which (to me) removes the already-existing, well-known, platform-agnostic, signal that you're dealing with a pointer. It also breaks the symmetry between declaring a pointer with type *a; and dereferencing it, with *a.

Database related, but prefixing tables with 'tbl' and stored procedures with 'sp' really winds me up.

I REALLY_HATE havingToRead CoDe With TOO_MANY UpperCase letTers in SymBol Names.

Can you imagine if books were written like that? No one would ever bother learning to read!

I would much rather see code in all lower_case with occasional capitalization and underscores to represent spaces in symbol_names.

I prefer ANY naming convention to BE used, over the complete lack thereof (which, unfortunately, is pretty much the case in many small development teams).

But my personal preferences are pretty much standard:

public class SomeClass
public void DoSomething()
private string thisIsAString;
protected TextBox txtPassword;
public interface IResizeable;

I have the habit of always using the same one-letter variables for specific, frequently-used tasks:

int i; // for counters, eg. "for (int i=0; i<=10; i++)"
int j; // for nested counter #1
int k; // for nested counter #2
int p; // for position lookup, eg. "int p = this.thisIsAString.IndexOf(foo)"
Control c; // for generic control

I use regions only for hiding large code blocks, only where clearly useful, and usually only within methods. I once did the same as in the example above, but it's proven too much hassle. I XML-comment EVERY class member, and that gives me enough visual separation.

We've had a programmer here who insisted on prefixing a random selection of variables with "wo". I think it stood for Workfile. And then he'd shrink down the variable name by removing the most salient pieces of information.

So in the example below, number "wohval" is actually used for a total price to be charged to a hotel. Obviously.

Integer WPrevind Bahh Bamm
Number Woldtot Wogross Wohval Wocval Wotval Wooval Wodcnt Wofval Wonocomm Wobkngfee
Number Woldins
Date Badate
String Woblethld Woldcncind

I don't care about what the naming conventions are. (although the region example might be going too far ;-) ) But I can get irritated with the way they're enforced. Just creating a coding guidelines document isn't enough. I've found that enabling policies like this works far better than just enforcing them.

Try to have automated checks running on your build server for stuff like this so you get early warnings about mistakes. Distribute settings files for your ide that help you do the right thing, use tools that help format your code like Resharper. Automate everything that can be automated. This actually saves time and irritation. Telling people what to do should be a last resort.

I once worked on a program where the original developer used a bizarre form of Camel Case that I've never seen anywhere else. The first and last letter of every word was capitalized. He also didn't follow that consistently, that naming convention was mixed with proper Camel Case as well as putting underscores between words.

function WeBForMDispoSelect_submit()
function WebFormRefresH(taskrefresh)
function LogouT()
function NeWManuaLDiaLCalL(TVfast)

A long time ago, a customer tried to force us to use a 100KB C header file in a project for them which redefined every operator plus a couple of other things. Example:

if (x _LT_ 5) { .... }

Plus they had some rules how to name things (name of the file in every function and global in that file, etc). You get the idea.

Since this was a fixed cost project, we politely offered them to do this ... and we offered the same result at half the price without this requirement. That was the only time in my life, when a budget meeting saved me :)

I have a couple of co-workers who instead of naming controls on a form like this:

Button btnOK;
TextBox txtLastName;
ComboBox cboAge;

name everything like this (in the designer - this code is just to illustrate the naming convention):

Button _btnOK;
TextBox _txtLastName;
ComboBox _cboAge;

in a weird hybrid of hungarian and private-variables-start-with-underscore. Has anybody ever seen this anywhere else?

The thing that really bugs me is when there is tautology in the naming standards -- you know, the sort of thing where file names must begin with "F" and database table names must end in "_table".

I'm still waiting for the 70's to end in the database world. You still frequently see people sticking to 8 character all upper case names where 4 of the letters are used to indicate the object type (table, etc). The field names are also all upper case, usually with the vowels removed, even when there's room to keep them in place. Most people even still use the all upper case convention for SQL commands even though SQL can actually be made to be a readable thing if lower or mixed case commands and field names are used. Sadly, I think the use of SQL will die before people realize that the style and naming conventions are making maintenance more difficult.

I don't like to use underscores in variable names, and regions for all combinations of access modifiers...

But what I hate most, is not having any convention at all and everyone just doing things as they see fit. I like spaghetti, but not when it comes to code.

At the company where I work, we use a software package called Macola. All the table names are heavily abbreviated, and all of them end with "_sql" just in case you forget how to get the data out of them.

TODO: Better Name ^[1]

private Int32[] rachelle(ArrayList arlst) {
    Int32[] arry = new Int32[arlst.Count];

    for (int i = 0; i < arlst.Count; i++)
    {
        arry[i] = (Int32)arlst[i];
    }

    return arry;
} // TODO: Better name!


private void rachelle1(ArrayList arlst, Int32[] arry) {
    arlst.Clear();

    if (arry != null)
    {
        for (int i = 0; i < arry.Length; i++)
        {
            arlst.Add(arry[i]);
        }
    }
} // TODO: Better name!


private Double? rachelle(string txt)
{
    // TODO: Think of a more appropriate name.  
    //       'rachelle' is really just a placeholder in this context

    Double? amt = null;

    if (txt != null && txt.Length != 0)
    {
        amt = (Double?)Convert.ToDouble(txt);
    }

    return amt;
}

This convention might just irritate me, but prefixing private variables depending on their accessor. For example, here is a C# example:

public class Parser
{
    private static string your_parser;

    private string my_string;
    ...

Perhaps it is just me, but I know StackOverflow will tell me in time ;)

Although it may be a personal preference I dislike the use of prefixing concrete classes with a capital C (like CBinaryFormatter). I do like the use of prefixing interfaces with an I (like IFormatter) so a bit of inconsistency there..

Upon starting my new job I inherited an application that named ASP.net form values the same as the ordinal position in a datareader/dataset and assigned values that way. i.e.

label0 = ds.Tables[0].Rows[0][0].ToString()
label1 = ds.Tables[0].Rows[0][1].ToString()
.
.
.
label10 = ds.Tables[0].Rows[0][10].ToString()

The developer even as far as to map out the names of the values in a huge comment block so they would not get confused!

"braces must go on a new line" I think it's important for brace style to be consistent. It's hard to parse code which has a mixture of styles. The particular style doesn't matter (although GNU style is insane).

"you shouldn't use the ternary if/else" Good advice, so long as it isn't enforced too tightly - there are occasions where it's nice. It's not a big sacrifice to give it up though.

As for the regions - I agree on this. Any source code that's just there for the editing environment is daft. This includes the changes made to make intelligence work that others have mentioned.

Things that irritate me personally:

• Inconsistent style.
• Deviating from the de-facto standard (if any) for a given language.
• Personal offense / religious objection to a style chosen for a project. Get over it.
• Hungarian (both type and scope, though type is much less forgivable)
• Objection to abbreviated names for short-scoped variables or single letter names for idiomatic code (i for for loops).

I also dislike "heavy" (as in formatting) commenting styles. It seems to be used as a substitute for good code structure.

I prefer a convention like this for for braces:

if (some condition){
  do;
  some;
  stuff;
} else{
  do;
  something;
  else; 
};

It's more clear for me. Not only has the benefits of this comments ^[1], it don't break the format convention.

you are not having a bad day, I worked with a special person that insisted on strongly typed namespaces.

namespace start
{
   namespace continue
   {
       namespace specific
       {
           className
           {
           }
       }
    }
}

which followed part of our naming scheme, but it was just not needed, especially when all that it was used for was to hide code flaws that wouldn't go away on their own without them. The code ended up looking like:

using start::continue::specific;
function( you_dont_know_where_Im_from );

This hides all the usefullness of namespaces in C++ of knowing where you were calling something. I'm glad I was recently tasked with removing this code (slight note of sarchasm as it was painful).

Special note: special person is no longer with us.

Apart from hungarian, which is just a ridiculously bad idea, the one "naming convention" that annoys me is the one that ignore the language rules.

In C++, identifiers with leading underscore followed by a capital letter (or another underscore), as well as any identifier starting with an underscore in the global namespace, are reserved to the implementation, and yet people try again and again to use these as variable names or class members. There may be similar examples in other languages, but this is the one I keep running into.

In general, as long as people follow the language rules, their naming convention doesn't bother me too much. Hungarian is silly because you end up specifying redundant information, and it becomes a pain to maintain, but eh, it's more or less readable and the code compiles. :p

One of our conventions is that all ID's need to be prefixed with an 'i' (id="iMain"). I hate it, it defines redundancy. I know it's an ID in HTML because it says "id=", and I know what it is in CSS because it's prefixed with a "#".

I guess that it's an offshoot of hungarian notation, I'll sometimes stumble across Javascript variables prefixed with obj_ and int_. I hate that, it's noise, I've never needed it.

I have to work against a legacy database at the moment. This thing is grown pretty big over the years, and for backwardscompatibility reasons we can't change it. We are using linq-to-sql which means a lot of code is generated. Every field starts with something like USE_ or even A_S_ and all in capitals.

First, underscores in the names annoy me a lot, because intellisense will work when typing lower-case, even if the fields or variables are CamelCase. But for that underscore you need to use Shift + '-', and for some reason I always have to look at my keyboard for the underscore.

And second, I always have to type at least 4 chars before the intellisense will be useful, at least because some fields are numbered at the end, A_S_FOOBAR1 and A_S_FOOBAR1.

secdonding @ unwind ^[1] on Hungarian notation.

I also hate using underscores to separate name like mysql_fetch_array in PHP.

I'm not a huge fan of CamelCaps, but they're better than underbars.

Personally I like running the name together in all lowercase so I don't have to worry about getting the wrong thing when I'm typing (no misplaced caps). I also try to use singleword functions and variables, or simple compound terms.

i actually like this naming convention you use although i make it a bit simpler (just ctor, public, private, protected). when opening the file i usually under which access modifier the method i'm looking for is under even if i don't know it full name so it shortens my search.

for class non public variables i use _ prefix. for public static and non static variables i use ThisIsMyField.

What drives me crazy is when you have the same field in multiple table with different names. If it is a PK, name it something you can use in all the child tables. If you must use it twice (say a PersonID which could be a sales rep or a customer), then use the name with a qualifier (CustomerPersonID, RepPersonID). Then it is always obvious which field joins to which one.

Right now I work on an app that has sales territories in it, in various tables they are district, territory, geography, geography_code (I'm sure there are more those were just the ones I could think of off-hand). Try remembering what the field is every time you write a query. This lack of consistency describing the same thing causes hours of extra work, trying different possibilities or looking them up every time as no one can remember all of them in all of the tables.

Using id for all id fields drives me up the wall. I don't want to have figure out what kind of id it is by translating the alias to the table in a complex query. And I do want to know immediately what field I should be joining it to in the table.

Then we have a developer who for some unknown reason separates his words in sp names or function names or variables with a $ instead of using FirstLetterCapitalization or an underscore. No one else in the company does this. It is fine to have a standard you prefer, but when the new company you go to doesn't use that standard, you need to let go of it and be consistent with the existing code base.

In a C# project, the coding standards made adding properties to our classes forbidden. Furthermore, if use of properties in the framework could be avoided, then we should do so.

A key metric for the same project was the number of lines of code. So, we wrote a VS snippet for adding Getter/Setter methods with lots of redundant checking and logging. Instead of 4 or 5 lines for a property, we used around 60 lines of code! It didn't help readability of maintainability, but it kept the management happy!

One case of butt-headed naming conventions I came across was on a database (I think it was DB2 for the AS400) where there were only 8 characters allowed for each column name. The convention was to start each column name with a T (for 'table'), then add a prefix for the schema, then add a prefix for the the table name, so after all the prefixes only 2 characters were left to actually differentiate the column names. You'd have T867CSFN for first name, T867CSLN for last name, T867CSA1 for address line 1, etc.

I despise everything about SQL conventions (or lack thereof)

• ALL CAPS keywords are unnecessary and ugly. Like someone said previously, modern environments will have syntax coloring, the CAPS is unnecessary, difficult to read and requires finger contortions to type.
• Infrequent indentation. I always indent my subqueries, select lists, where clauses, etc. As illustrated by coworkers and examples on the web, I'm in the minority.
• Comma as the first character on a line. Why is this OK in SQL and inappropriate in every other language known to man?

• Microsoft's illegible examples. They make UNIX man pages look like a children's board book.

   < column_definition > ::= column_namedata_type
      [ COLLATE < collation_name > ] 
      [ [ DEFAULT constant_expression ] 
          | [ IDENTITY [ ( seed ,increment ) [ NOT FOR REPLICATION ] ] ]
      ] 
      [ ROWGUIDCOL] 
      [ < column_constraint > ] [ ...n ] 
  

Overall, most people I've worked with don't follow any conventions at all and when they do they are horribly ugly. Last job I had was working for a major bank with 15,000+ employees. No guidelines on coding style. Whenever I got SQL queries from other developers the first thing I'd do was spend 20-30 minutes re-formatting their nonsense so that I could understand what they were trying to do. As an aside, that 20-30 minutes was not an exaggeration. Only a very small handful of DBAs were allowed to use functions or stored procs, so queries written by everyone else were routinely 100, 200, 500 lines long. This is part of the reason why they are a former employer. ^_^

I hate following,

1. Database Table or member names with underscore in it, example Customer_Table, Customer_Name etc
2. foo, bar (need real life names to understand logic used in context)
3. Some indian's C book using variable names as xxxxx, yyyyy, vvvvv

int variableName;
typedef  ...  TypeName;
int function_name();
class ClassName
int _memberVariable;

int mVariableInModuleScope;
int gVariableInGlobalScope;
int kConstant;
int *pPointerVariable;
int *gpGlobalPointerVariable;

Happily we also have the rule that if the style rules detract from maintainability, then the rule may be ignored.

A very simple, and common one; I don't like interface names prefixed with 'I'. Interfaces should be generally descriptive, with the implementations more descriptive still. I do not want to see a collection of ICustomer ... I want to see a collection of Customer.

Hungarian sucks, of course, for variable names (not to mention being pointless in loosely/dynamically typed languages, but "tbl" prefixes are helpful for tables).

If possible, I start all class names and variable names that hold a class with capital letters; all others start with lower case. Some folks find this annoying.

P.S. What's the beef with ternaries? They make a nice, tidy one-liner and aren't hard to read at all. True, if there are clusters or nesting of ifs, it's better to use expanded form.

In modern development languages and environments, C++ included, scope is more important than type, the compiler will inform you of type miss matches but not scope. To this end I favor a simple but effective naming convention -

• a = argument
• m = member
• l = local
• g = global

Very simple example -

class Foo
{
    private:

    	int mBar ;

    public :

    	Foo ( int aBar )
    	: mBar ( aBar )
    	{
    	}

    	int GetFooBared ( int aMultiplier )
    	{
    		int lBar = mBar * aMultiplier ;
    		return lBar ;
    	}
} ;

static Foo gFoo ( 10 ) ;

int main ( int aArgc, char* aArgv [] )
{
    int lFoo = gFoo . GetFooBared ( 10 ) ;
    return lFoo ;
}

A hybrid of hungarian/scope prefixes/qualifiers that was (possibly still is) used for C++ code in a company I used to work for:

c vl_tag_c

Local variable that holds a char

l Pvl_length_l

Local variable that holds a pointer to a long int

m Uvm_size_m

Constant member variable that holds a pointer to a non-constant unsigned long int

m Pcm_size_m

Non-constant member variable that holds a pointer to a constant unsigned long int

c, l and m are actually typedefs, as are h, i, j and x. Why? To deliberately trip you up if you try to use them as variable names (they are not considered "descriptive" enough.)

Python's __self__ for accessing the instance inside of a class. Why all the underscores? Were they going cheap that day? C# just uses a keyword for it: this. Seems to make much more sense. Were they afraid of making self a keyword?

VariableNamesLikeThis suck. It should be variable_names_like_this.

If I find the moron who first popularized VariableNamesLikeThis, I will PunchHimInTheFace.

• I despise anything other than lowercase 'id' for an id field in a database.

• I despise even the merest hint of capital letters in any variable, function, class, etc.

• I despise groups of variables where the hierarchy is ignored. ('maxblah' and 'minblah' instead of 'blahmax' and 'blahmin');

Other than that I'm easy :)

This will be quite controversial, but I don't like giving parentheses, brackets, and braces their own line.

Proper indentation should show the structure quite well (look at Python). If you feel insecure about your ability to always close the environments, use an editor that can help you.

Not giving braces their own lines reduces the linecount by up to 1/3. This means that you can actually see up to 50% more of your code on a single screen. If you feel that you need empty lines to separate parts visually, you can still add them.

I know that this goes against brace-language tradition, but I find

if (some condition)
   { do;
     some;
     stuff; }
   else
   { do;
     something;
     else; };

more appealing than

if (some condition)
{
    do;
    some;
    stuff;
}
else
{
    do;
    something;
    else;
};