Difference between revisions of "Programming Guidelines"

Revision as of 18:54, 4 August 2008

Initial starting point: LJ Programming Guidelines.

Now, let's talk a bit about how Dreamwidth code should be written. Note that this is the stylistic guideline to follow to make sure the code looks uniform. If you submit a patch that doesn't follow these guidelines, then it will likely get declined with a note to review this documentation. Realistically, we want everybody to be able to dive into the code and understand what is going on without having to try to interpret a dozen different coding styles.

Note that these are not hard and fast rules. A lot of the time you will be fixing up code somewhere that is broken, and you will want to follow the style of the code you are working in. If you're editing really old pages like talkread.bml then you should attempt to code legibly, but follow the style in use on the page. (Mixing styles within a file can be problematic.)

These are guidelines, and not to be afraid of! Please don't feel intimidated by the style of the code. People will help you out if you have questions or aren't sure how to write something.

• Spaces. Yes, we use spaces. There are four per level of indentation. But use your judgement when you're lining things up.

• Use postfix conditionals. That means:

   # This is incorrect:
   if ( $something ) {
       do_something();
   }
   
   # Try this instead:
   do_something() if $something;
   
   # Or even:
   do_something()
       if $something;

It is your discretion which of the forms you use. Pick whatever seems appropriate to the code. (I tend to prefer the latter personally unless the line is really short.)

• Spaces around parenthesis and operators. Perl has a well-deserved reputation for being line noise. Let's try to avoid that.

   # This is right out:
   if ((($a||$b)&&(($c>1)||$d&5))+1)>3) { ... }
   
   # This is much better:
   if ( ( ( $a || $b ) && ( ( $c > 1 ) || ( $d & 5 ) ) + 1 ) > 3 ) { ... }

Well. It's better, but this line is terrible anyway. If you end up with a line like this, I'd suggest rewriting it entirely. Don't be too afraid of going onto multiple lines if it makes the operation more readable.

The "space around parenthesis" rule also applies to method calls. Here are some examples of when this comes into play:

   call_method( $arg, $arg2 );
   
   do_something( 45 ) if $org || $neg;

However, do NOT use parenthesis around operators used to index into arrays or hashes. It gets confusing.

   # Wrong:
   if ( $array[ 13 ] > $hash->{ $index } ) { ... }
   
   # Right:
   if ( $array[13] > $hash->{$index} ) { ... }

• Don't use extraneous parenthesis. This happens mostly on method calls that don't need it and postfix conditionals.

   # These are wrong:
   my $r = DW::Request->get();
   do_something() if ( $r->method() eq 'POST' );
   
   # Fixed:
   my $r = DW::Request->get;
   do_something() if $r->method eq 'POST';

Note that you need parenthesis after bareword function calls such as the do_something() above. Otherwise Perl has no idea it's a method and not a constant or some other value. But when you call it on a reference (using the -> operator) then it's assumed to be a method.

• No tabs, ever. No trailing whitespace.

These things happen. I'll try to catch them before commit. But don't commit tabs or trailing whitespace. Convert all tabs to spaces and prune trailing whitespace.

• Use human logic. This is a big one that will really help people reading the code. The human brain is good at some things, bad at others.

   # if something is true is easy to understand:
   if ( $whatever ) { ... }
   
   # unless something is true is also easy to understand:
   unless ( $whatever ) { ... }

However, some things are NOT easy to understand, and should be rewritten.

   # don't use this unless you REALLY need to
   if ( ! $something ) { ... }
   
   # use this instead:
   unless ( $something ) { ... }

In some cases, the variable in question lends itself to the negation syntax in the first example. But that's a rare case. Just think about it for a second and go with what flows.

   # never use this
   unless ( ! $foobar ) { ... }

There is no situation in which "unless not $something" makes sense. The brain just doesn't parse it. It's a double negative, you might as well just use "if $something" and call it good!