views:

3345

answers:

44

What programming or naming conventions have you come across that really rub you the wrong way?

For those that aren't aware, in C# we can wrap blocks of code with a #region directive, which allows you to collapse these blocks in Visual Studio for readability.

So the convention on this team is to wrap all combinations of access modifier in their own region. Every time I open a file I'm presented with something like:

+ #region private constants
+ #region private members
+ #region private statics
+ #region public properties
+ #region static constructor
+ #region private constructor
+ #region public properties
+ #region protected overridden methods
+ #region internal methods
+ #region private methods

Well that's great, but where's the method that maps the message response onto our object? Is it an internal method, or a public one? Why does the private members region only have one member, turning one line of code into three? Why add a region to describe something that is self descriptive?

Maybe I'm just having a bad day...

+35  A: 

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

Geo
I think this used to be the MS-recommended way of doing it, which makes it just obsolete rather than idiotic (although sticking with the obsolete is pretty idiotic).
MusiGenesis
Er, I dont think naming conventions that indicate scope are idiotic. Type indicator naming conventions are obsoleted due to sophisticated IDEs but they dont help with scope. When I am dealing with a variable, I like to know the extent of its effect.
Gowri
Sophisticated IDEs can show the variable name in a different colour/font depending on the scope.
finnw
This convention is so dumb and we are now stuck with it.
Trumpi
m_ is easily broken by making it a public variable. It's just a crappy variant of hungarian.
jcollum
"m_" indicates member, not private. How would making it public change anything? Also in most OOP languages there's a "this" or "self" keyword (or variable) which allows you to reference the member variable. Using it would make the prefix unnecessary (and redundant)
sebnow
It even gets worse when the convention is c_ for member variables (they call it class variables here, hence the c), m_ for local variables (they call it method variables here --> can you imagine the confusion with the by mfc default generated m_ variables for members) en p_ for all method parameters (i'm really not kidding)... Please bear with me ;-)
fretje
+1  A: 

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.

Mladen Prajdic
+42  A: 

Hungarian notation 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.

unwind
i use hugarian for naming controls. like btnSave or lblText... easier to find in intelisense.
Mladen Prajdic
@Mladen: me too. That one's pretty ingrained in Windows developers.
MusiGenesis
Use SaveButton and TextLabel instead, and save 1000s of keypresses every week, when using hungarian notation you are destroying the intention of intellisence. You have to do 4 keypresses before even Start to get to what you want.
Stefan
I am comfortable with Hungarian notations too. Makes the code easily understandable, readable etc. Ofcourse the reasons that Stefan gave above are very good. But I see many developers hate them too much.
goths
I have one question: How do I differentiate between a class member and a local variable if I use "SaveButton" and "TextLabel"? In Hungarian Notation we prefix with m_
goths
@Stefan: agreed! I can't stand btn lbl txt ddl et al...
g .
When using Visual Studio you have ten different ways to find out what a scope a variable has. Hold the mouse over the variable, press CTRK-I and some other ways. For me and many other its information you get when you need it, it does not have to be visible in the name.
Stefan
I can't stand Hungarian notation in the slightest. Mainly for the fact that I do not see a place for abbreviations in naming. As far as control naming is concerned, ButtonSubmit and ButtonCancel are just as easy to find as btnSubmit and btnCancel.
joseph.ferris
Is that Systems Hungarian or Apps Hungarian?
finnw
@Jospeh, yet better is SubmitButton, with the verb first. ;)
Stefan
There's different kinds of Hungarian. I like the kind where the prefix conveys the intent of the variable, like "i" for index, "n" for number-of, "b" for boolean. I hate needlessly wordy and ambiguous names, like "inputFile". Is that an object or a name?
Mike Dunlavey
@Mike, if its ambiguous, then add more. InputFileIOStream,InputFileTextBox,InputFileString, InputFileChooseDialog and so on. I also hate when its ambiguous.Instead of _filestring to hold a property value, use FileStringPropertyHolder.
Stefan
I'm a Windows programmer who hates Hungarian notation. You can't imagine how conflicted this makes me!
John Dibling
As a Hungarian, I feel ashamed that this is what people think about when they think about my fine nation. Here, we call it Bulgarian Notation.
Gregg Lind
Dude I'm bulgarian. Show some respect >_>
@ Mladen: I've heard of a better convention for this: uiCustomerName etc. Prefix anything that is visible to the end user with ui. That way you won't have to change the name if uiCustomerName changes from a label to something else.
jcollum
btw, cmdStart is a camelStyle
abatishchev
@jcollum, I like that idea, but what if you have lblAmount and txtAmount?
Blorgbeard
LOL @Gregg Lind... I call it Canadian...well just because.
kenny
+27  A: 

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.

unwind
Amen. Technically PX is for near pointers and LPX is for far pointers, which adds to the confusion; nobody's needed near/far pointers in decades.
Adam Rosenfield
+1  A: 

secdonding @unwind 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.

warren
apparently underscores make the most easily readable names. That's a good reason to use them in your naming convention. You already use all lowercase anyway!
gbjbaanb
Larry Wall prefers _ in Perl because he says its easier for non-English speakers. I use _ in Perl and camelCase in C# partly as a mental switch. If I see _, it's likely Perl, if I see camelCase, it's likely C#.
John Ferguson
if we could use hyphens, I'd be all set.. but for some reason compilers don't like it when you try subtracting function and variable names from each other :)
warren
@warren, if functions were verbs and variables were nouns, you wouldn't really try subtracting "robot" from "exterminate"
sebnow
@sebnow - that is likely, but doesn't affect the way the names are typed-out
warren
John: I know Larry said that, but the non-English speakers I know don't tend to agree.
Ken
IReallyWishIUnderStoodWhatTheReSistanceWasToUnderScoresInIdentiFierNamesToSePaRateWordsInAMoreLegibleFashIonTheWayWeDoWhenEverWeAreWritingEnglishInSteadOfGerManYouKnowRightEh?
tchrist
+5  A: 

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?

MusiGenesis
yes and I couldnt understand it either....
redsquare
Not to mention that some names starting with an underscore are reserved for the implementation. As Herb Sutter recommended, I just don't use them. That way I don't have to remember the exact rules.
David Thornley
@David Thronley: That's a C and C++ rule and does not apply in C# (the language that MusiGenesis must be referring to if he's using a "designer")
Billy ONeal
+5  A: 

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.

Mendelt
+56  A: 

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
...
Tony Andrews
OMG! that's brilliant!! :)
Mladen Prajdic
Was he optimizing his code for 32-bit processors? (snicker)
MusiGenesis
I think he came from RPG, did he?
dhiller
Personal conventions are not much to worry about (however silly.) It's when they become company-wide coding standards that it's a problem.
finnw
shoot - that's nothing! if he were a C64 programmer, he'd know to only use 2 characters!
warren
By ex-chief likes VB.NET and name variables like Dim LBL As LocalBinaryLink, EPC As EnvironmentPerformanceCounter so on and in ONE line! I think he is an idiot/code-monkey
abatishchev
I have to live with this every single day :(
Davide Vosti
Linux kernel and libraries are full of garbage like this. Full names are a lot more useful as they often save you from digging up the documentation for the thing just to remember what the abbreviation meant.
Longpoke
+37  A: 

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.

Guillaume
Hahah! That takes the cake :PServiceAble!
Ace
+1. This one is adorAble
Binary Worrier
I have recently moved in direct defiance of the 'able' convention. Instead, I use something like "IAmAProjectsRepo" for repository pattern stuff , "IStoreImages" for datalayer dependencies. Sometimes I take it a bit too far, though: I once had a component of an Xna graphics engine I was working on called "IDrawThings". I'm not sure if that is brilliant or punishable.
Dusda
+5  A: 

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.

Vincent Van Den Berghe
+1 for the spaghetti comment! :D
AviD
+2  A: 

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..

soren.enemaerke
Is that a C++ thing? I saw it all the time with C++, but haven't seen it with C#.
g .
It's a Microsoft thing. Before that, a common C++ practice was to start each class name with T.
Ferruccio
I'd rather prefix the class than the interface. Interface names appear more frequently so I'd rather make them shorter.
finnw
I've only seen it in a single C# codebase but found it really anonoying since it didn't follow the standard set by the BCL
soren.enemaerke
Oh, I thought the T prefix was a Borland/VCL/Delphi thing, learn something new every day :)
Crippledsmurf
+32  A: 

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...

DoctaJonez
I only use single variable for indexers: i, j, k. Ingrained from math class I spose.
jcollum
I agree with jcollum, but I also use single letter variables for very short term temporary uses. Like a duplicate of "prev" or "newline" shortened to 1 character while its transformed and immediately used ... everything *else* is sensibly named.
The Wicked Flea
I only use single letter variable names for indexers and lambda expression variables
DoctaJonez
+5  A: 

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".

James Anderson
How exactly is this a tautology?
Draemon
I guess he meant "redundancy."
mquander
Because it's always true that it sucks
Robert Fraser
+13  A: 

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.

You really use "j" as a nested counter? You must have really good eyesight.
MusiGenesis
I do to, depends on the font.
Rich Bradshaw
I agree entirely, though I use nested FOR loops so rarely I don't have a specific pattern, other than "i" is the usual counter.
Neil Barnwell
If you have nested loops, using single letter variables is a BAD idea. I'd rather associate the counter to some other variable (the enumerable), e.g, "peopleCounter" or "peopleIndex", then you can easily see what the index refers to.
sebnow
Its fine for iterating through coordinates, having the incrementors called X and Y makes sense there. The only think i do differently is this: Private String _thisIsAString;
Pondidum
A: 

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 ;
}
titanae
Ugh. I can break this by defining a changing the scope of a variable without changing it's name. You've just invented a bastardization of Hungarian.
jcollum
"aArgc" this hurts...
Nikron
Couldn't you just use `this`?
Brendan Long
Do not take this as personal offence, but this is seriously the worst possible way to name variables.
Marek
+15  A: 

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.

Ferruccio
maybe_if_you_put_the_capitalization_in_the_correct_spots_then_you_can_read_it_easier. Hmmmm...your way looks pretty nasty, IMHO.
Dunk
Underscores really gets me annoyed though, too_many_can_ruin_your_code
LiraNuna
That's why I said *occasional* capitalization and underscores. Neither is bad in small doses.
Ferruccio
So I take it you're not a fan of PascalCasedClassNames ?
Billy ONeal
I don't think I've ever seen a book that_put_underscores_between_words, either. In fact, I'm learning Japanese right now, and they often don't even put spaces between words or punctuation at the end of a sentence
Ken
+9  A: 

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
seanyboy
Sounds like Wookie-speak!
Ace
woW... that's woRse than underscores :))
luvieere
Did he work for woot! ?
Chris Lively
+5  A: 

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.

Nerdfest
There be science behind that SQL convention! With a limited set of known keywords to recognise, you don't need so much attention to read uppercase, so "SELECT blah FROM blah WHERE blah='blah'" is more readable to the majority than "select blah from blah where blah='blah'". Which is easiest to you?
jTresidder
I think it's been repeatedly shown that all upper case is very difficult to read. It distracts the eye away from the important part as well ... the field and table names. Also, the upper case is usually not limited to just keywords.
Nerdfest
Agree with nerdfest, upper case is harder to read.Not indenting is also provably shown (read the human factors engineering studies) to be more legible than indented text, but try getting a programmer to believe that too!
HLGEM
Not to mention that all modern SQL editors have syntax highlighting, which obviates any special convention to identify keywords. I write all my (T-)SQL in lowercase, with identifiers cased correctly.
Ben M
HLGEM: What human factors engineering studies are these?
Ken
A: 

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;
};
Svante
I'm in the open-brace-same-line club. However, your method trips me up because of the 2 levels of indent for a single code block.
spoulson
Arrghh! My poor eyes! I couldn't live with anything that didn't match indents for open/close brackets, even with Notepad++'s highlighting function. I'm not that fussed about how much code is on a screen at one time as long as I have a mouse-wheel... Different strokes and all that I guess :)
JoeBloggs
I'm with JoeBloggs. I'm afraid to blink in case the code above is burned onto my retinas. Blessed be your mind Harlequin, but I'd end up weaving baskets if I'd to look at that all day :)
Binary Worrier
JoeBloggs, how do you cope with Python?
Svante
spoulson, the `if` statement has three arguments: a `(condition)` and two `{block}`. Each of these start their opening parenthesis/brace in the same column. The contents of the blocks are one level deeper, and therefore indented.
Svante
Note that the `else` keyword would actually be superfluous, if every statement had to end with a semicolon, but many of these bracy languages imply a semicolon in a closing brace, but only in some cases, and in those cases, with exceptions... talk about consistency.
Svante
I don't use python, but why? Does it choke when using a brace on a line by itself?
JoeBloggs
No, Python doesn't use any braces for code blocks, just indentation. Have a look at some Python code.
Svante
I'm with Joe and Binary on this one. Seeing more code doesn't help if it's less readable. If you need those extra lines, it might be time to refactor.
Scott
I think that "readability" is not only subjective, but also undergoes fashion trends. Currently, many programmes seem to think that BASIC code was very readable.
Svante
A: 

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.)

finnw
+24  A: 

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

unochild
hear hear! By all means, prefix a view or a function, but I think it's safe to assume the object after "SELECT * FROM" is going to be a table!
jules
Actually, it could be a view. The point is, it really shouldn't matter ... it's a thing that provides data.
Nerdfest
+1, dumb convention that I deal with daily.
jcollum
Furthermore, at least in MS SQL Server, when calling an SP that begins with "sp_", MSSQL assumes that its a system SP, and first looks for it in the master catalog; only after not finding it does it look for it in the local db. So not only is this specifc one dumb, its wrong and bad, too.
AviD
Oh, I'm on a project that is the worst offender of table naming conventions I've ever seen. There is a table that stores 'projects', objects with a name, some sizing information, and an fk to an images table. For reasons passing understanding it is called "tblSUDefinedClientMasterLibrary".
Dusda
This is high on my "moron" list.
Chris Lively
+1  A: 

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.

Simon Scarfe
+2  A: 

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, it don't break the format convention.

damian
Yea - this is now my preferred style as well. +1
Huntrods
Is the "){" and "else{" on purpose? Seems inconsistent with the left side. I hate it when there are spaces after keywords when there don't need to be any, like "if (", and I especially hate "if ( isSomething )".
sebnow
The first thing I do when either working somewhere else or installing a new machine is "fix" visual studio to use this exact style.
Chris Lively
+1  A: 

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.

MacX.dmg
A: 
  • 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 :)

JoeBloggs
Right, because there are no capital letters in English proper names.
Bryan Watts
JB: +1 on all points, especially the hierarchy!BW: Give me case insensitivity and you can capitalise your function names HowEVeryOuLiKE() :)
jTresidder
Camel casing is not arbitrary - first letter of each word is uppercase. Easy and unambiguous. The issue is multi-word tokens and how to represent them. Underscores require an extra character per word, while capital letters are inline. "_" is jarring in a name - you can't think without pauses :-)
Bryan Watts
I'm not so much saying that it doesn't make sense, as I'm saying that I don't like it (personal preference). Ambiguity does creep in, albiet rarely, but worst of all function() is not the same as Function(). Why not? Why encourage one of those hidden-in-front-of-your-face type bugs for no benefit?:)
jTresidder
I despise id variables named id. They are horible for complex queries.
HLGEM
Because longvariablenameid is much easier to read than LongVariableNameId.
weiran
+1  A: 

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

jalf
+5  A: 

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 :)

Aaron Digulla
I remember learning how to do this in a programming class. This part of the class was started and closed with "If I catch anyone doing this, you will fail my course." I really liked that professor.
Chris Lively
Why would you use _LT_ over '<'? It's less readable AND longer. The only reason I can think of is for embedding in a webpage, but there are better ways than that.
Wallacoloo
+6  A: 

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)
Asa Ayers
Maybe he was shifting too soon/early: <shift>w</shift>e<shift>bf</shift>or..., <shift>L</shift>ogou<shift>T()</shift>.Still pretty idiotic though.
sebnow
I'Ve had shift keys stick where I ended up with WEbFOrmDIsposSElect... Of course, I always notice and fix immediately; if not sooner.
Chris Lively
A: 

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.

Nerdfest
I agree, not sure why this one came about.
jcollum
@jcollum: The geniuses at Microsoft.
sebnow
+2  A: 

"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.

Draemon
Single-letter identifiers like `i` are difficult to search for if you're working on code without an IDE that understands the language. Short scopes sometimes get longer or get other short scopes with conflicting names get wrapped into an existing scope and have to be deconflicted. And I just think using descriptive identifiers is a good habit.
Blrfl
+1  A: 

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.

Sorskoot
+2  A: 

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!

Miyagi Coder
A: 

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?

jcollum
I could do with removing the "self" parameter, as that usually trips me up after a break from Python. Having "self" as a variable is fine though. self.foo() and this.foo() is exactly the same. You can even use "this" instead of "self".
sebnow
No it's the damn underscores that seem lame to me.
jcollum
`self` usually isn't surrounded by double underscores (although it can be since `self` is just a parameter name, not a keyword). Double underscores are used to mangle the names of "really private" methods.
mipadi
Doesn't anybody remember how to use `__FILE__` and `__LINE__` — and the reason for the double underscores? Or for that matter, `__GNUC__` or `__STDC__` and so on and so forth?
tchrist
A: 

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.

Clayton
+1  A: 

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.

HLGEM
+5  A: 

TODO: Better Name

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;
}
Evgeny
+2  A: 

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 ;)

daub815
A: 

VariableNamesLikeThis suck. It should be variable_names_like_this.

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

smcameron
I don't mind camel case, but I prefer the first letter to be lowercase.
daub815
It depends entirely on the language. You will be laughed at if you name variables with underscores in C#.
weiran
The fact that one doesn't mind camel case, or that one will be "laughed at" for use of underscores in C# does not make Camelcase any less stupid.ThereIsAReasonPeopleDon'tTypeSentencesThisWayAndTheReasonIsTheSameReasonThatCamelCaseIsFarkingStupid.It_is_far_more_readable_this_way_idiots.
smcameron
+4  A: 

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.

Scott
+1  A: 

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!

Stewart
+1  A: 

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.

Nathan Hughes
A: 

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. ^_^

kubi