In my first job out from school I worked with a bunch of ex COBOL programmers who were re-writing the system in this new-fangled language called "C".<p>One convention was that all "procedures" should be prefixed with a name indicating where they were in the call graph of the program.<p>So the main method was always:<p><pre><code> int main()
{
a_initialize();
b_process();
c_shutdown();
}
</code></pre>
The first function called by a_initialize had to be called "aa_", then "ab_" and so on:<p><pre><code> void a_initialize()
{
aa_connect_database();
ab_read_accounts();
ac_read_ledger();
...
}
</code></pre>
and so on.<p>Of course, sometimes you had to write a function that had to be called from more than one place (strange I know!!)<p>For this, the naming convention "pzzDDDD" was used where D was a digit from 0-9. "p" for procedure and "zz" because these functions didn't belong to any one place in the hierarchy.<p>We had a print out of the "pzz"s because just the number was hard to remember. But I can still remember a few of them:<p>* pzz0030 was for looking up account information from the database (but also for maintaining this information).<p>* pzz0031 for contracts<p>* pzz0241 I think was for looking up fees and commissions.<p>Most of the "functions" had lots of parameters so that they could do different things (modify, update, delete accounts etc.). This soon became unwieldy so eventually you had:<p>* pzz0241_a_setupcharges()<p>* pzz0241_c_cleanup()<p>or something. I forget the details for this last bit.<p>This was in 1997.<p>Neat huh? ;-)
Not so much strange, as Twilight Zone-esque insane: <i>All methods and properties must be commented with XML</i>.<p>Sounds like a good idea, until you see how this turns terse and readable code into a bag of chatty noise. Basically this:<p><pre><code> public enum ConnectionState {
Disconnected, Connecting, Connected
}
</code></pre>
Was not compliant ("There's no comments! It's not readable!"), while this:<p><pre><code> /// <summary>
/// The Connection State.
/// </summary>
public enum ConnectionState {
/// <summary>
/// The Connected State.
/// </summary>
Connected,
/// <summary>
/// The Disconnected State.
/// </summary>
Disconnected,
/// <summary>
/// The Connecting State.
/// </summary>
Connecting
}
</code></pre>
Was considered Compliant and Good. This example has not been simplified, by the way.
<p><pre><code> > To NEVER remove any code when making changes. We were told
> to comment all changes.
</code></pre>
I'm afraid given this rule, I would abuse it horribly. My backspace key would no longer function and every typo I make would introduce a new set of /* */ comments. Every refactoring would have the old type, variable, line, function, or entire class commented out with the fixed code alongside it. Bonus points for interleaving the old code and replacement code.
The strangest coding standards were imposed when I was working at an AS/400 shop a dozen years ago.<p>No indentation allowed. Even though the modern compilers supported it, it looked ugly to veterans who had worked with fixed-format compilers for 30 years.<p>No comments in the code allowed. The function had to be entirely clear by looking at the code. Any code that needed comments for clarification was considered too 'clever' and 'obfuscated' for production.<p>No new language features allowed. IBM maintained languages and tools always acquire large amounts of feature bloat over the decades. Only a small subset of these features was 'white listed' by the CTO.
I worked at a start-up whose engineering lead brought familiar coding style to a project that was inherited. We were imposed a combination of C89-esque and Microsoft kernel coding style on an Objective-C source code. Things like defining all variables at the beginning of the function definition in alphabetical order in CamelCase, having instance variables prefixed with the class abbreviation, and other inane rules. It went something like this:<p><pre><code> - (void)
doSomethingOnObjectAndNumber:
(NSObject *) MyObject :
(NSInteger) MyNumber
/*++
Some unstandard doc format.
--*/
{
...
return;
}
</code></pre>
Before I started, I was told that the project migrated from git to svn to "make branching easier". I do not work there any more.
Maybe someone knows of a solution but it would be great if SVN/version control was able to store a standard formatted version of source code and then depending on client/user preferences could reformat the file accordingly on checkout and then also be able to factor in / unformat when doing diffs/checkins. I feel like if it could work like this it would mitigate a lot the inevitable battles that take place over small things like formatting/etc. There are obviously things like variable names that it wouldnt be able to solve but at least nobody would be complaining about where Joe put his curly bracket. I guess you can do something similar with an SVN hook but its hard to get a seamless process.
The company must scale! Sysadmin and webdev must be split! Therefore all (junior, barely unix-aware) web developers must provide automated Freebsd-specific install, test, start and stop scripts in a custom and ill-considered package format with no inter-component runtime or instllation-time dependency support. For every project. Therefore the perlmonger in charge and sysadmin extraordinaire can automate their dabblings.<p>Needless to say, getting barely PHP capable people who'd heard of unix to automate dependency installation and maintenance on such a platform didn't work out well. Did I mention this was 2010?
In one project, I had to use camelCase and cargo-cult-Hungarian prefixes in table objects: tblTableName, sVarcharColumn, iIntegerColumn, vViewName and so on. I actaully surprised myself with just how deeply and viscerally I hated this convention. I could no longer easily convert column names into human-readable headings on reports; and the prefixes were just redundant, completely missing the point [1] of Hungarian Notation.<p>[1] <a href="http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%2...</a>
The strangest one was when I was a COBOL programmer in the mid 80's and was forced to learn and used the GOTO verb. Having learned COBOL JSP style I was unaware that goto even existed in COBOL until then.<p>There again same place made me retest a program I'd tested and was fully working as a full-stop was missing of a comment line.<p>Crazy days.
Many answers show a common trend: absurd prefixing rules. They're not only useless, but also counterproductive, because they prevent the incremental searches that are present in so many parts of the development tools.<p>If you prefix every table name with "tbl", you can't search for them in the DB manager console, the IDE table listing, a directory list of the creation scripts, etc.<p>I suffered an extreme version of this: there was some prefix that was also the directory name. So the files were called "prefix/prefixBlah". Also the prefix was used as class name and the fields were also prefixed with it.<p>The result was that a reference could become "prefix/prefixBlah/prefixBlah.prefixDoh", an awful noise to signal rate.<p>I complained without success. That way was "a lot more orderly and tidy" <sigh>.
I was talking to someone today, and they commented:<p>"Good programmers eventually learn to misspell words like void or int so that they can name their variable names what they want to name them."<p>I of course told him that this was terrible advice, and would mess with the next person who had to maintain the code because you couldn't tell at a glance if a word was a keyword or a keyword mispelled. I asked him what language he was using.<p>FORTRAN.<p>Where did he work.<p>The United States Air Force.<p>For how long?<p>Six years.<p>When?<p>Before 2000.<p>Since he had more experience, he claimed I was de facto wrong.<p>I fought him on it some more.<p>He told me it was personal preference. I told him you'd have to make me do it.<p>It was at that moment I figured that someone, somewhere, had probably had to do this as part of a coding guideline.
On a vaguely related note, there was a project kicking around a month or so ago to store editor-neutral code formatting specs in the project root. Can anyone remember what it was? My google-fu is failing.
None were strange. I agreed with all the coding standards I have been forced to follow. The key to not be annoyed by them is to not work at places enforcing stupid standards :)
In my first job as part-time programmer at a bank back in 89, we were developing a large system in C, pretty advanced stuff compared to the usual 'buy from IBM' approach at the time. The 'systems analyst' broke down the design into modules and functions for the entire system, and everything was named something like 'ABM10EI00405'. Yeah, those were the actual names we had to use for .c files and functions.
I've come to believe that coding standards always end up being either too simplistic to deal with every scenario or longer and just an inferior in-house implementation of Steve McConnell's "Code Complete". Either way you're wasting your time<i>.<p></i>Style guides are ok though, so long as they're short and not enforced too bluntly.
No numerics permitted in function names.<p>Theory: It's prettier.<p>Reality: Just try to understand the hierarchical relationship between 247 functions in a 10,000 line Material Requirements Planning module of an ERP system when every function name must be all alpha.
That is why <i>only</i> products made by engineers for themselves should be re-used (nginx, redis, etc.) and those been "managed" by idiots should be avoided.)<p>Over-management is much more common and much worse problem than over-engineering.)