image
Archives

0

Worst coding standard you've ever had to follow?


Have you ever had to work to coding standards that:

  • Greatly decreased your productivity?
  • Were originally included for good reasons but were kept long after the original concern became irrelevant?
  • Were in a list so long that it was impossible to remember them all?
  • Made you think the author was just trying to leave their mark rather than encouraging good coding practice?
  • You had no idea why they were included?

If so, what is your least favorite rule and why?


Some examples here



- Archives
image

Archives

0
#define AND  &&
#define OR   ||
#define EQ   ==

'nuff said.



- Archives
image

Archives

0

Had a professor once who demanded we have at least one comment for each line of code.

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

It was pretty ridiculous.



- Archives
image

Archives

0

I was asked by the software leader of a company to do "simple, rendundant code". It was forbidden, for example, to add a new parameter to an existing function. You instead had to duplicate the function, leaving the original untouched in order to avoid regressions. No formal testing of course (waste of time).

We were also forbidden from using merge software; each file could only be modified by one programmer at a time. Revision control software was science fiction, of course.

The happiest day of my life was when he was fired (consider that it is very, very difficult to fire someone in Italy).



- Archives
image

Archives

0

All interaction with the database has to be done through stored procedures. It might make sense if we're living in 1997 and not 2010.

I just realized that this actually covers all the criteria of the original question:

  • Greatly decreased your productivity? CHECK. Please - just use an ORM.
  • Were originally included for good reasons but were kept long after the original concern became irrelevant? CHECK. The manager was a developer for a database server 1000 years ago and put this coding standard in.
  • Were in a list so long that it was impossible to remember them all? CHECK. This included 'as much logic should be stored in the database as possible'.
  • Made you think the author was just trying to leave their mark rather than encouraging good coding practice? CHECK. Keeps coming back to the manager being an ex-database server developer.
  • You had no idea why they were included? CHECK.


- Archives
image

Archives

0

Enforced XML comments on all non-private methods, constants, enums, and properties.

It led to some pretty cluttered code, especially since the end result was people either just hitting /// to create an empty comment stub for everything or installing GhostDoc and having it add auto-generated comments:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[Edit] The reason I mention this as a ridiculous standard isn't because I think method comments are stupid but because the quality of these comments wasn't enforced in any way and resulted in just creating lots and lots of clutter in the code files. There are better ways of creating meaningful code docs than blind "must have a comment" build requirement.



- Archives
image

Archives

0

This may ruffle a few feathers, but standards that mandate templated block comments at the top of each method always bug the crap out of me.

1) They are always out of date since they are too far from the code that does the actual work to notice when you are updating things. Bad comments are worse than no comments.

2) They often just repeat information that is already contained the source control tool, just less accurate. For example: Last Modified by, list of modification date/reasons.



- Archives
image

Archives

0

In one job we were forced to use some weird form of Hungarian notation in the database.

I can't remember the details, but from memory, each field name had to contain:

  • No vowels
  • All uppercase letters
  • A reference to the table
  • A data type indicator
  • A data length
  • A nullable indicator

For example, the column holding a person's first name might be called: PRSNFRSTNMVC30X (Person table, First Name column, Varchar 30 characters, Not Null)



- Archives
image

Archives

0

I find many of the Mono coding guidelines to be pointless or counter-productive. For example:

  • 80 column limit - considering we're all using widescreen monitors these days is just wasting the limited vertical space we don't have, and not making use of the horizontal space we do have.
  • Tabs for spaces - perfect way to make your code look like a mess when opened in different editors which have different tab sizes. (Also, eight space tabs is just wasting the very limited 80-columns you have to work with anyway).
  • Inconsistent brace positioning, for what reason? What's wrong with 1TBS?

There are a number of other guidelines there which are just "good practices", without reasoning.



- Archives
image

Archives

0

Like a lot of programmers (but not enough), I hate code decoration. It infuriates me when I have to use a dollar sign($) prefix for variable names, or underscores for private variables, even with no getters/setters. If you need to decorate you code to understand it, then you need to get the hell out!



- Archives
image

Archives

0

Hungarian notation

Sample extracted from "Charles Simonyi's explication of the Hungarian notation identifier naming convention" on MSDN.

1  #include “sy.h”
2  extern int *rgwDic;
3  extern int bsyMac;
4  struct SY *PsySz(char sz[])
6      {
7      char *pch;
8      int cch;
9      struct SY *psy, *PsyCreate();
10      int *pbsy;
11      int cwSz;
12      unsigned wHash=0;
13      pch=sz;
14      while (*pch!=0
15        wHash=(wHash11+*pch++;
16      cch=pch-sz;
17      pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18      for (; *pbsy!=0; pbsy = &psy->bsyNext)
19        {
20        char *szSy;
21        szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22        pch=sz;
23        while (*pch==*szSy++)
24            {
25            if (*pch++==0)
26              return (psy);
27            }
28        }
29      cwSz=0;
30      if (cch>=2)
31        cwSz=(cch-2/sizeof(int)+1;
32      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33      Zero((int *)psy,cwSY);
34      bltbyte(sz, psy->sz, cch+1);
35      return(psy);
36      }


- Archives
image

Archives

0

I once worked on a project in which the project lead mandated that every variable - EVERY variable - be prefixed with "v". So, vCount, vFirstName, vIsWarranty, etc.

Why? "Because we're working in VBScript and everything is a Variant anyway".

WTF.



- Archives
image

Archives

0

Forcing inline comments for version control was about the most pointless coding standard I ignored.

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

The Oracle DBA that insisted on correct use of whitespace while 'maintaining' a database with a highly contended table that had over 200 fields and 40 triggers comes close.



- Archives
image

Archives

0

Maybe The Huawei Software Company's coding standard. They want you to declare all members public:))



- Archives
image

Archives

0

Our company (C#) coding standard called for extensive use of #REGIONs (for those who don't know, it marks blocks of source code that will be collapsted to a single line in Visual Studio). As a consequence, you always opened what seemed to be a nicely structured class, only to find piles and piles of garbage swept under deeply nested rugs of #REGION constructs. You'd even have regions around single lines, e.g. having to fold out a fold out a LOG region to find one single declaration of the Logger. Of course, plenty of methods added after some region was made, were placed in the "wrong" region scope as well. The horror. The horror.

Regions are one of the worst features ever added to Visual Studio; it encourages structuring the surface rather than the actual OO structure.

Nowadays, I kill #REGIONs on sight.



- Archives
image

Archives

0

I worked in a project were the chief architect demand to write (way too) explicit code. One of the worst examples I found in the code (and he happily approved) was the following.

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

Even ReSharper told you this is wrong!



- Archives
image

Archives

0

Writing anything in Fortran (WATFOR, FORTRAN 77) where a non-whitespace character in column 1 was a comment, and the compiler didn't warn you if you went beyond column 72, it would just silently ignore it.

At least I only spent seven years doing this.



- Archives
image

Archives

0

In Visual Basic 6.0, we had to add error handling blocks to every single method. No exceptions. So we did.

Then we had to explain why parts of the application were slow.



- Archives
image

Archives

0

Having what amounted to C header files, in a Java project.

Interfaces exist for some good reasons, but this standard mandated an interface (foo.java) for every single class (fooImpl.java) whether it made any sense or not. Lots of stuff to keep in sync, complete disruption of Eclipse click-into-method, pointless busy-work.

The build system enforced it, but I cannot imagine what the original purpose was. Fortunately we ditched it for new code when we switched to a new version-control and build system, but there's still a lot of it about.

At the same time we also ditched the stupid version-control-info-in-file-comments habit which had been mandatory.



- Archives
image

Archives

0

Mandatory inclusion, expansion of $Log$ information when our SCC was antiquated version of PVCS. We had some files where the $Log$ information was much, much longer than the actual code in the file.



- Archives
image

Archives

0

Limited space for variable/object names is probably my largest irritation. I've worked in a relatively modern, proprietary language that only allows 10 characters. This is a holdover from its original versions.

The net result is that you end up with funny naming conventions defining what each character of your allowed 10 is to represent. Something like:

  • 1-3: application prefix
  • 4-6: module prefix
  • 7-9: user defined section
  • 10: a number just in case two...or 9 are named the same thing.


- Archives
image

Archives

0

In my life as C++ coder, two really nasty "rules" were enforced:

  1. "We can not use the STL, because VC++ 4.1 does not support it (and we can't switch to VC++ 6.0 at this time)."
  2. "Do not use QuickSort, because it can be O(n^2) in bad cases; use this implementation of the HeapSort algorithm I (name of project leader deleted) wrote as a student."


- Archives
image

Archives

0

The worst was a project (C++) where classes were prefixed with module abbreviations.

For example, if something was in the MessagePassing module, and part of the Response mechanism, it might be called MESPAS_RESSomeobject.

Working on that code made me want to gouge out my eyes.


Not the worst, but my current job requires a c_ prefixes on classes and e_ prefixes for enums. Nothing for structs. but _t postfix on typedefs. It's pretty ugly too.

Oh, and function header comments in BOTH .h and .cpp (declaration and definition) which of course almost never match.



- Archives
image

Archives

0

Being required to indent all code by four spaces ;)



- Archives
image

Archives

0

Some of the places I've worked with insisted on commenting out unused or deprecated code instead of deleting it. Instead of trusting the VCS for history, etc. it was painfully maintained in the files through commented out code.

The big problem I found with this is that you often had no idea why the code was commented out. Was it because some dev was actively making changes and wanted to keep it around for reference or was it no longer needed?



- Archives
image

Archives

0

I currently work in a company where SQL queries are done through something called "Request Class". How ridiculous:

In "include/request.class.php"

class RequestClass
{
    // ... some code.

    public function getUser($where)
    {
        global $initrequest

        $sql = $initrequest['users']
        $sql.= $where;

        return execute($sql);
    }
}

In initrequest.php:

$initrequest['users'] = 'SELECT * FROM users WHERE ';

And it was called from the application in this way:

$request = new request();
$tmpquery = "username = $username AND password = $password";
$request->getUsers($tmpquery);

And they have a similar template system based in "blocks", but after understanding what I show here, I kept pressing to trash our whole software and rewrite it in Symfony.



- Archives
image

Archives

0
  • Local variable names are all lowercase with no underscores

Real examples: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts, potentialmsceventref

The New York Times weighs in:

“Word spaces should not be taken for granted. Ancient Greek, the first alphabet to feature vowels, could be deciphered without word spaces if you sounded it out, and did without them. […] Latin, too, ceased to separate words by the second century. The loss is puzzling, because the eye has to work much harder to read unseparated text. But as the paleographer Paul Saenger has explained, the ancient world did not desire ‘to make reading easier and swifter.’”


- Archives
image

Archives

0

My favorite would have to be the database naming guidelines we currently are trying to abide by. All tables used for many-many relationships should be named using the names of the linked tables and must be suffixed with "Link". And of course, no pluralization of table names.

  • OrderLines? Nope. It should be called OrderProductLink
  • Friends? Nope. It should be PersonPersonLink


- Archives
image

Archives

0

My favorite is the "No magic numbers" rule applied cluelessly. For example, I once saw a comment in a code review stating then the "No magic numbers" rule had been violated by this line of code:

if (fscanf(file, "%s %hd",name, nbrObject ) != 2 )

I guess the reviewer wanted a constant instead of 2, such as #define TWO 2



- Archives
image

Archives

0

At my last job, "standards" would be a very strong term for what I was given by the guy who hired me. Programming websites in ColdFusion and SQL, I was given coding requirements like:

  • Don't use includes. I like one big page
  • Always separate words in variable and column names with underscores (except isactive, firstname, etc.)
  • Never use abbreviations -- always write out firstname (he frequently wrote fname and so forth)
  • Don't use confusing names (like amount_charged and charge_amount, which measured differnt but related things)
  • Don't use DIVs, and use minimal CSS -- use nested tables instead (I found some six layers deep, once).
  • Don't cache any queries. Ever.
  • Going to use a variable on more than one page? Application scope.
  • Each page is its own try/catch block. We don't need/want a global error handler.

I started changing these as soon as he quit.



- Archives
image

Archives

0

Not being allowed to use the STL or other standard C++ libraries because the CTO believed 'we' could do it better and faster. Even basic constructs like lists and the string class.



- Archives
image

Archives

0

Insisting that all braces be followed by comment for what the brace ends:

e.g:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For


- Archives
image

Archives

0

Not really a coding standard, but we had a file in source control called 'changelog.txt'

Every time you made a checkin, you had to manually add an entry to this file. This entry was the subversion revision number and your checkin comment.

When the new CTO started and someone told him this, he promptly made an executive decision and said, "We're not going to do this anymore" and deleted the file. This had been going on for years.



- Archives
image

Archives

0

I've been working with a web system for a while where all parameters passed had to be named P1, P2, P3 etc. No chance in hell to know what they where for without extensive documentation.

Also - although not strictly a coding standard - in the same system, every single file was to be named xyz0001.ext, xyz0002.ext, xyz0003.ext, etc - where xyz was the code for the application in itself.



- Archives
image

Archives

0

All output in a PHP script must be echoed line by line.

<?php
echo "<div id=\"foo\">";
echo "<h1>" . $title . "</h1>";
echo paragraphs($body); // just an example
echo "</div>";
?>

(Disclaimer: I didn't have to follow it, but a team I worked with did.)



- Archives
image

Archives

0

The worst coding standard I've ever participated in is code bases which had none at all. I'd rather follow a coding standard I completely disagree with than work in code bases where there is none at all. It makes it that much harder to learn new parts of the code base.



- Archives
image

Archives

0

This more an example of how not having coding standards can hurt.

A contractor working at a large bank insisted that following the standards were the best ever. The application was written in dBase/Clipper which he was the sole developer for and of course he came up with the standard.

  • Everything is in upper case. I mean everything, including the rare comments he made.
  • No indentation.
  • Variable naming was something along the lines of APRGNAME. A = scope of variable, eg P for public, PRG = first three characters of the source file that created the variable, NAME = variable name in the remaining 6 characters that dBase/Clipper allowed.
  • The first 4 and last 4 lines of the source code were 80 * long. Why? So he could hear the dot matrix printer starting and finishing the printing of a file. Memory is the entire program was printed via the mainframe weekly, 20,000 pages.
  • I'm sure there were many more that I've managed to dump from my brain.

I was a very new self-taught programmer at that stage but knew enough not to listen to the mad scientist and get the hell out of there before I asked to take over the project.

And yes we told management how bad these practices were but always got the usual "were paying this contractor top dollar he must know what he's talking about".



- Archives
image

Archives

0

At one company we had to write technical documenation that explained how we will write a functionality. It fast got out-dated since you wont think about everything when youre programming in UML.



- Archives
image

Archives

0

This was a LONG time ago -- 1976 to be exact. My boss had never heard of Edsger Dijkstra or read an issue of CACM, but he had heard a rumor from somewhere that "GOTO is bad", so we were not allowed to use GOTO in our COBOL programs. This was before COBOL added the "end if", so at the time it had only two-and-a-half of the three classic control structures (sequence, if / then / else, perform (i.e. do while)). He grudgingly allowed GOTO in our Basic programs, and branch instructions in our Assembler language programs.

Sorry that this is a sort of "you had to be there" story. As far as I know, every language invented since 1976 has adequate control structures so that you never need to use GOTO. But the point is, the boss never knew WHY GOTO was considered harmful, or which language was the infantile disorder and which was the fatal disease.



- Archives
image

Archives

0

I did code reviews on a project led by a C++ first timer who decided that all class member functions should be prefixed with the class name and visibility:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}


- Archives
image

Archives

0

I'm forced to have XML documentation for all classes and class members. Including private. I'm encuraged to use default ghostdoc comments.

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}


- Archives
image

Archives

0

Being forced to add a file description in each file (it's a C# project).

// --------------------------------------------------------------------------------------------------------------------
// <copyright file="User.cs" company="Company">
//   Copyright (C) 2009 Company. All rights reserved.
// </copyright>
// <summary>
//   The user.
// </summary>
// --------------------------------------------------------------------------------------------------------------------


- Archives
image

Archives

0

"Do not use C++ comment style for C code".

While this may still have a small value if there is risk of needing to port your program to an obsolete compiler, it's mostly just a hassle. My biggest objection is that it makes it really hard to use /* to block comment out a large region during development or unit testing. */



- Archives
image

Archives

0

No more than one line of code allowed in Main()

A professor at my university who I was fortunate enough not to have insisted that her junior C# students not be allowed to put more than one line of code in their console applications' entry point.

This makes a reasonable amount of sense when developing a professional application, but when the program's only intent is to take few basic inputs and produce a single output (i.e. MultiplyTwoNumbers.exe), such a requirement is more pain than good.

On top of the "one line of code in main" the professor also insisted that every line of code have a descriptive comment and every class member have a verbosely descriptive name. Points lost if the professor didn't feel that these requirements had been met "adequately".

The students forced to stick to these rules were (almost) all newbies to programming and thus I can see the value of enforcing conducts like good-naming and separation of concerns. Despite that, as the .NET Tutor at my university I was constantly helping her students meet these mundane and obnoxious requirements long after they had gotten their code working.

In my opinion, when educating someone who is brand new to a programming language the first concern should be how to create code, not how to create standards-based code.



- Archives
image

Archives

0

Nearly any sort of variable naming convention that reiterates the variable type, mutability, scope / storage class, and/or their reference. Basically, any construct intrinsic to the language. This is no longer necessary in the 21st century with modern IDEs (and in my opinion only originally solved poor code layout / practices to begin with). This includes hungarian notation and its variants:

  • bigBlobStr - A string.
  • bigBlobStrCurLocPtr - A pointer to the "current location" in said string.
  • someIntArray - Array of integers

or things like:

  • e_globalHeading - External variable
  • sg_prefPoolSz - Static global variable

and of course one the farthest reaching eyesore in OOP, m_ for all members. If you can't be sure / keep track of which variables are local, members, globals, static, or final/const, you might be writing unclear, poorly factored, spaghetti code.

This is wholey different than specifying a prefix/suffix convention for things like min, max, avg, size, count, index, et cetera, which is fine.



- Archives
image

Archives

0

I worked for a short time in Japan. I was doing complex mathematical coding. The company coding standard was to have absolutely no comments. It was difficult as I would have liked to add some comments to explain the complex calculations and not forget myself after few weeks. Pity the next guy who comes after me to understand what the code was doing.

It was the first time I ever saw that coding comments were prohibited.



- Archives
image

Archives

0

At a previous job, the C# standard was to have at least two spaces between type name and variable name in declarations, the method name must begin on the next line from the access modifiers and return type, a space must occur before any open-punctuation (parenthesis or bracket), all variable declarations at the beginning of the method, declarations separate from assignment and the indentation was 3 spaces. Example:

private static int
ThisIsTheMethod (int  code, string  message)
{
   int  i;
   int  j;
   int  k;

   for (i = 0; i < message.Length; i++)
   {
      if (message [i] == '!') return -1;
   }

   j = SomeMethod (code);
   k = OtherMethod (j);

   return k;
}

While ugly, it was workable with the exception that Visual Studio really didn't want things that way and it was more an extra step after coding "normally" to reformat it as this.



- Archives
image

Archives

0

(C++)

All return values had to be HRESULTS (the standard ones - not user defined hresults)

This was just a few years ago. The senior people were still so infatuated with COM and they never read or learned of other best practices. It was an amazingly closed environment.

The same place also did not allow using STL.

I left shortly after I found out that tidbit.



- Archives
image

Archives

0

I had a job years ago where all our code had to be left-aligned - no indenting. The guy who came up with that policy disliked having to scroll back and forth horizontally when viewing long lines of code, equating it playing ping-pong with his eyes.



- Archives
image

Archives

0

Worst standard I've ever had to face:

StyleCop for C#

Take every pointless standard ever and put it into a tool that runs at compile time instead of in the IDE at design time.

//this is not a legal comment.
//  nor is this

// must be followed by a single space, if you are debugging, use //// to comment code. Properties must also have 'triple slash' comments and they must read "Gets or Sets xxxxx" complete with a period at the end and properly capitalized.

Ugh. Maybe there's a point with widely published APIs but my main beef is they surely could have built it as a plugin a la R#.



- Archives
image

Archives

0

Our method names had to be in the format 'Get/Set/Add/Delete' + name of the target object + names of all the parameters.

GetUserById(userId);
InsertUser(user);
DeleteUser(user);

Fair enough - but the rule very strict. Complex object types were not allowed to be abbreviated, and operations always had to list every request parameter, no matter how ridiculous:

GetCustomerOrderDeliveryDetailsByCustomerIdAndDeliveryDateAndOrderStatus(...

After adding in the full variable names (which weren't allowed to be shortened, either) you can imagine how long some simple method calls were. Word wrappingly long.



- Archives
image

Archives

0

Almost forgot this one:

Quote from a manager:

Do not fix or document any bugs of issues you find in your own code. The customer will pay us to identify and fix them over the next few years.

This wasn't for consumer software, but custom for a single large organization. Needless to say, the customer did pay for years afterwards. May seem trivial, but trying to ignore bugs is harder than finding them.



- Archives
image

Archives

0

One more blast from my past.

Quote from company owner:

There will be no code written using interpretive languages because I lost 25 million on that {expletive} project written in Java.

The Java project was a stock trading system designed to handle a few dozen stocks, that was now being used to process thousands. Instead of addressing the design flaws or poor hardware, the whole company was forced to convert all non C/C++ applications to C/C++, and all new development had to be in C/C++. Interpretive languages meant anything not compiled, and the owner only considered Assembler, C and C++ compiled.

For an 800 person company, in which most of the code was in Java and Perl, this meant the whole company spent most of their time over the next couple of years rewriting perfectly fine code in C/C++.

Funny enough, some twenty years before this fiasco, I was at another company in which the tech lead decided that our sorting logic (it was a Bubble Sort) needed to be recoded in assembler instead of being replaced by Quick Sort because -- Algorithms do not improve performance. The only way to improve performance was to rewrite the same logic in assembler.

In both cases, I left shortly after the dictates came down.



- Archives
image

Archives

0

at my previous job, which I gladly quit 3 months ago:

database:

  • Table names had to be uppercase.
  • Table names had to be prefixed TBL_
  • Fields had to be prefixed: DS_ (for varchar, which made no sense) NU_ for numbers CD_ for ("bit fields") DT_ for dates
  • database fields had also to be uppercase [CD_ENABLED]
  • same with sp names [SP_INFINITY_USER_GROUPS_QRY] and database names [INFINITY]
  • did I mention sp names were actually like that? SP_ prefix, then database name SP_INFINITY_ then table name, SP_INFINITY_USER_GROUPS then what the sp was actually expected to do (QRY,UPD,DEL,INS) jesus, don't even get me started on queries that weren't just CRUD queries.
  • all text fields had to be varchar(MAX), unequivocally.
  • numbers were either int or double, even when you could have used other type.
  • "boolean" fields (bit) were int, no reason.
  • stored procedures had to be prefixed sp_productname_

asp.net / c# / javascript

  • EVERY single function had to be wrapped in try{}catch{}, so the applications wouldn't "explode" (at least that was the official reason), even when this produced things not working and not having a clue why.
  • parameters must be prefixed with p, e.g pCount, pPage
  • scope variables had to be prefixed with w (as in "working", what the hell does that even mean?)
  • statics with g, etc.
  • everything post framework 1.1 was offlimits, like you had any real uses for linq and generics anyways. (I made it a point to enforce them to let me use jquery though, I succeded at that, at least).


- Archives
image

Archives

0

Where I'm working now the variable naming process for anything dealing with the database is:

  • $sql for statements
  • $result for query results

Which makes sense, however when I brought up the point that the convention was too generic and that this would end up with variable overlap the response was "use result_alt or sql_alt." My feelings on commenting, if you used proper variable names that signify purpose you wouldn't need comments or as many of them.



- Archives
image

Archives

0

My ADA lecturer at uni insisted that every method had a comment outlining preconditions, postconditions and big O. The biggest issue with this was that he never bothered to explain what big O actually meant and never checked if they were correct so I found myself copying and pasting this comment block hundreds of times.

-- Method_Name
-- PRECONDITIONS: none
-- POSTCONDITIONS: none
-- O(n) = n


- Archives
image

Archives

0

The worst coding standard I ever had to follow was "All object variable names must be prefixed with 'obj'". This was on a big Java project, so almost everything was an object. The worst part was, almost everyone adopted a policy of naming variables by simply prepending "obj" to the class name. We wound up with stuff like Person objPerson1 throughout the code. I objected once, and had one of the other developers interject that she liked the convention "because then I don't have to think about my variable names". That place was a real horrorshow...



- Archives
Cancel