text: dueDate or due_dateBumpyCase has the advantage that DueDate is clearly a class while dueDate is clearly an instance. BumpyCase also makes individual program statements a little shorter and less likely to wrap across multiple lines. Do we indicate the type of identifiers in how we choose their name? A common system is:
  CONSTANT, Class, instance, subroutine.The name of a subroutine is usually clear from context since it's followed by parentheses. At the opposite end of the spectrum, HungarianNotation embeds a lot more type information in a name. Any special way of indicating data members or private members? Some people use a prefix, like _ or m_:
  class PhoneNumber { private: unsigned int m_areaCode; unsigned int m_exchange; unsigned int m_lastFourDigits; public: PhoneNumber(string& phoneNumber); CallResult call(); ... };In non-OO languages, where you have to fake classes, how do you create the fake namespace for a class? A common solution is to combine BumpyCase and underscores, like this:
  void MboxParser_create(); ErrorCode MboxParser_open(char *filename); MailHeaderField* MboxParser_getHeaderFields();Do you name an array after the singular or the plural of the kind of element it contains?
  MailHeaderField field[]or:
  MailHeaderField fields[]Using the plural has the advantage that you can write code like this:
  for (int i = 0; i < numFields; i++) { MailHeaderField *field = fields[i]; parse(field); // etc. }or in PythonLanguage:
  for field in fields: field.parse()2. Where do you put the braces? In other words, like this: (Lisp- / Smalltalk-style)
  if (condition) { doSomething(); }or like this:
  if (condition) { doSomething(); }or like this:
  if (condition) { doSomething(); }or like this:
  if (condition) { doSomething(); }or like this:
  if (condition) { doSomething(); }or like this (actually spotted it somewhere, but don't remember):
  if (condition) { doSomething(); }Similar questions need to be asked for any multiple-line construction with delimiters; for example, a function declaration with arguments that (for whatever reason) should be split over several lines:
  def foo(spam, eggs, beans):or
  def foo(spam, eggs, beans ):or
  def foo(spam, eggs, beans ):or
  def foo( spam, eggs, beans):or
  def foo( spam, eggs, beans ):3. Indentation Indentation of 2 columns or more than 4 columns tends to be hard to read. An advantage of 3-column indentation over 4-column is that while both are readable, 3-column indentation makes shorter lines that are less likely to go past 80 columns and wrap. In some languages, like CascadingStyleSheets, 2 columns can actually be more readable. 4. Tabs Do you include tabs (ASCII 9) in your source files or not? Each tab represents one level of indentation. If you include tabs in your source files, then everyone can set their editor to expand tabs to however many spaces they like. Except not really, since people insert a different number of tabs to make things line up depending on the tab setting. ViEditor and others can be set ("set expandtab") to automatically convert the tab keystroke into the appropriate number of spaces. When indentations are stored as spaces, program code is readable in gdb, on a printer, in email, etc. In those places, the tab character expands to 8 spaces, causing code with one tab per indentation to spread out so much that it's almost unreadable. PythonLanguage requires consistency of tabs and spaces, so it almost mandates the "expandtab" approach. 5. Type on same line as function definition? Like this:
  MailHeaderField* MboxParser_getHeaderFields() { . . . }or like this:
  MailHeaderField* MboxParser_getHeaderFields() { . . . }The first way has the advantage that tools (like ctags) can easily find the beginnings of functions, since the function name always occurs at the beginning of the line.
  // Constructors /** * This is a default constructor. It does nothing of consequence. **/ public JavadocClass() { super(); }This snippet is about 50% comments, it has the required constructor comment, and it doesn't do anything. Couldn't you just write something like:
  /** Obligatory default ctor. */instead? -- MikeSmith I remember reading some JavaDoc guidelines that mentioned the problem of how coders who fill in all the required fields often give redundant information that could be gleaned from the code alone -- I mean the pieces of code that are included in the JavaDoc, e.g. variable names. They said that of course you shouldn't introduce mindless redundancy, but rather try to provide a description that contains more information. Personally, I treat almost every place for a potential JavaDoc comment as optional; the JavaDoc utility doesn't really complain :-) Consider
  int Point.getX() { return x; }This would hardly benefit from a comment saying
  /** * gets the value of the x coordinate of this Point * @return value of x coordinate */Of course, you could provide more information by using the terms abscissa and ordinate in the comments for getX() and getY() respectively, instead of repeating the names x and y. A nice way of reminding the reader of which is which. However, it only makes sense if this isn't mentioned already in the description of the class and if these terms are actually used elsewhere in the program/documentation. A compromise I often employ is to provide only the @return clause. As you see, in practise all redundant/superfluous (parts of) JavaDoc comments can be safely omitted and nothing bad will happen. The problem with this is that you can hardly write a CodingStandard around such terms, because then everyone would just invent his/her own definition of "redundant", "superfluous" etc. and procede as he/she pleases. I guess this is the reason why so many 'fields' were declared required in the first place. -- NeKs Even the redundant types of javadocs are valuable if one does not have access to the source code and the javadoc is the only available documentation, however.
  } finally { if (out != null) try { out.close(); } catch( Exception ignored) {} }
  if(condition) { //big block } if (condition) { shortBlock(); } if (condition) { statement1; statement2 ; } if (condition) { statement1; statement2; statement3; }Anything that makes the code nicer to read (of course in the subjective judgement of the guy who writes the code), is allowed. Overly restrictive or overly specific coding standards are kind of stupid, IMHO. For example I read in one coding standard that the choice operator ? : should not be used at all. --Costin
  if (happy) then ... else ... instead of : if (unhappy) then ... else ...2)Replace negative variable names with positive ones.
  happy = true if (happy) then ... instead of : unhappy = false if (not unhappy) then ...More rules to be defined :) mailto:zimba_AT_@oree.ch