Clean Coding - Common Sense

[Chandler]

Originally Posted by Skyld

No. Ideally you should not be omitting brackets.

One to their own I suppose

[Skyld]

Originally Posted by Grey

With functions I always use brackets, with statements I tend to omit them if there is only one command by force of habit, but I do usually indent it still and move it to the next line. If there is an else following the if however I always use brackets. Personally I just find it looks a lot nicer that way. As far as spacing goes I agree with HR.

PHP Code:

function checkStyle() {
  if (this.style == true) {
    increaseAwesome();
  } else {
    decreaseAwesome();
  }
  if (noelse == true)
    omit = true;
} 


PHP Code:

function checkStyle()
{
  if (this.style)
  {
    this.increaseAwesome();
  }
    else
  {
    this.decreaseAwesome();
  }

  if (this.variable)
  {
    this.otherVariable = true;
  }
} 


Originally Posted by Chandler

One to their own I suppose

I guess, however I promote clean styling for a reason: to promote editability, understandability and just overall cleanliness. Leaving brackets out is hardly efficient; say you want to add something later into your conditional code block, you'll then need to add brackets which you could have just done to start with!

[xXziroXx]

Originally Posted by Skyld

Leaving brackets out is hardly efficient; say you want to add something later into your conditional code block, you'll then need to add brackets which you could have just done to start with!

Row count ++

[Gambet]

Originally Posted by xXziroXx

Row count ++

legibility ++

[godofwarares]

Bleh, I code like this:

PHP Code:

function doSomething()
{
     stuff();
     moreStuff();
     
     if (x == 2)
     {
          doEvenMoreStuff();
     } else {
          ohWell();
     }
} 


[Inverness]

Heres a sample of my coding, I'm extremely picky about the formatting.

PHP Code:

public function loadRefs(obj) {
  temp.i;
  temp.e;
  temp.vars;
  temp.count;
  temp.ref;
  
  vars = obj.getVarNames();
  count = 0;
  for (i = 0; i < vars.size(); i ++) {
    if (obj.(@ vars[i]).type() == 1) {
      if (MudControl.isRefStr(obj.(@ vars[i]))) {
        ref = obj.(@ vars[i]);
        obj.(@ vars[i]) = MudControl.parseRef(ref);
        obj.(@ vars[i]).addRef(obj);
        count ++;
      }
    }
    else if (obj.(@ vars[i]).type() == 3) {
      for (e = 0; e < obj.(@ vars[i]).size(); e ++) {
        if (obj.(@ vars[i])[e].type() == 1) {
          if (MudControl.isRefStr(obj.(@ vars[i])[e])) {
            ref = obj.(@ vars[i])[e];
            obj.(@ vars[i])[e] = MudControl.parseRef(ref);
            obj.(@ vars[i])[e].addRef(obj);
            count ++;
          }
        }
      }
    }
  }
  echo(format("References Loaded (%s): %s %s", count, obj.mudtype, obj.mudid));
} 


[xXziroXx]

Originally Posted by Inverness

Heres a sample of my coding, I'm extremely picky about the formatting.

PHP Code:

public function loadRefs(obj) {
  temp.i;
  temp.e;
  temp.vars;
  temp.count;
  temp.ref;
  
  vars = obj.getVarNames();
  count = 0;
  for (i = 0; i < vars.size(); i ++) {
    if (obj.(@ vars[i]).type() == 1) {
      if (this.isRefStr(obj.(@ vars[i]))) {
        ref = obj.(@ vars[i]);
        obj.(@ vars[i]) = parseRef(ref);
        obj.(@ vars[i]).addRef(obj);
        count ++;
      }
    }
    else if (obj.(@ vars[i]).type() == 3) {
      for (e = 0; e < obj.(@ vars[i]).size(); e ++) {
        if (obj.(@ vars[i])[e].type() == 1) {
          if (this.isRefStr(obj.(@ vars[i])[e])) {
            ref = obj.(@ vars[i])[e];
            obj.(@ vars[i])[e] = parseRef(ref);
            obj.(@ vars[i])[e].addRef(obj);
            count ++;
          }
        }
      }
    }
  }
  echo(format("References Loaded (%s): %s %s", count, obj.mudtype, obj.mudid));
} 


Your styling is practically the same as mine

[DrakilorP2P]

A general guideline is to keep the formatting as similar to the rest of the project as possible. It might be a good idea to write a general guideline that all developers abide to.
Here's how the Angband source code is styled:

PHP Code:

written by Robert Ruehlmann, Ben Harrison, and Gwidon S. Naskrent

There are lots of things that are commonly considered good style for Angband code. The Vanilla Angband source code is the general guideline.

Here are some of the "rules":

    * Don't use floating point calculations.
    * Don't break savefile compatibility (if not absolutely necessary).
    * No C++ code. That also means no '//' comments.
    * Put system dependent code between #ifdef xyz ... #endif /* xyz */ .
    * No "magic numbers". Use #defines. The #defines should be in defines.h rather than the source file, unless they're very local (such as dungeon generation parameters). 

And some code-style guidelines:

    * Comments, comments, comments. Multi-line comments should look like:

      /*
       * A multi-line
       * comment.
       */

      instead of:

      /* A multi-line
       * comment */

    * Indentation with tabs. But generally avoid getting lines over 80 characters.
    * Put curly braces ('{', '}') on an extra line with the same indentation level as the previous line. Example:

      if (value == 0)
      {
          do_something();
      }

    * Put empty lines between code-blocks. Example:

      /* Do something */
      do_something();

      /* Do something else */
      do_something_else();

    * Spaces around the mathematical, comparison, and assignment operators ('+', '-', '*', '/', '=', '!=', '==', '>', ...).
    * Spaces between C-identifiers like 'if', 'while', 'for', and 'return' and the opening brackets ('if (foo)', 'while (bar)', ...).
    * No spaces between function names and brackets and between brackets and function arguments (function(1, 2) instead of function ( 1, 2 )).
    * If the precedence of operations is ambiguous then put brackets around them. Also try to insert parentheses whenever necessary for readability, eg. around (foo & RF3_SOME_DEFINE). There is usually no ambiguity and no macro resolution, but this is an aesthetic detail.
    * If a function takes no arguments then it should be declared with a void argument list. Example: int foo(void) instead of int foo().
    * Function declaration and definition should look the same.
    * Don't assume that functions declared without a return type return int. Specify the type explicitly. Example: int foo(void) instead of foo(void). 


[Inverness]

Originally Posted by xXziroXx

Your styling is practically the same as mine

Note how I use temp variables. It is something I began doing only recently and it makes the script look much more organized rather than using temp. repeatedly before all the temp variable names.

[xXziroXx]

Originally Posted by Inverness

Note how I use temp variables. It is something I began doing only recently and it makes the script look much more organized rather than using temp. repeatedly before all the temp variable names.

I use temp variables all the time too!

[Rapidwolve]

What does

PHP Code:

prefix.varname; 


do? Is there really a point to it? does it declare it or something

[Inverness]

Originally Posted by Rapidwolve

What does

PHP Code:

prefix.varname; 


do? Is there really a point to it? does it declare it or something

Yes, I use that for temp variables only, it declares the variable as a temp so it can be referenced without the use of temp.

When you have variables defined in function parameters they're declared as temp variables and you're able to reference them with or without the temp. before the variable name, this is the same idea.

I place all the temp declarations at the beginning so I know what all I'm using and can make notes for other people using it.

[cbk1994]

Originally Posted by Rapidwolve

What does

PHP Code:

prefix.varname; 


do? Is there really a point to it? does it declare it or something

Declares the variable, so it's value is "" not NULL.

[Kristi]

Originally Posted by Inverness

Note how I use temp variables. It is something I began doing only recently and it makes the script look much more organized rather than using temp. repeatedly before all the temp variable names.

Um, you can't do that, when you say vars = something, you're actually assinging it to vars, not temp.vars

PHP Code:

function onCreated() {
  temp.hello;
  hello = 2;
  sendtorc("TEST:" @ temp.hello);
  sendtorc("TEST2:" @ hello);
} 


Yields the following:
The best idler is the (Server): TEST:
The best idler is the (Server): TEST2:2

note that temp.hello is still null. The only way to drop the temp is if the var was passed as a paremeter, it will take presedence over an already global var.

On another note, ziro, grey, and inver all have good styling imho

[Riot]

Originally Posted by Kristi

Um, you can't do that, when you say vars = something, you're actually assinging it to vars, not test vars

PHP Code:

function onCreated() {
  temp.hello;
  hello = 2;
  sendtorc("TEST:" @ temp.hello);
  sendtorc("TEST2:" @ hello);
} 


Yields the following:
The best idler is the (Server): TEST:
The best idler is the (Server): TEST2:2

note that temp.hello is still null.

On another note, ziro, grey, and inver all have good styling imho

I was about to comment on this too:

PHP Code:

function onCreated() {
  temp.i;
  
  i = 34;
  echo("onCreated(): i =" SPC i SPC "temp.i=" SPC temp.i);
  test();
  
  this.setTimer(1);
}

function onTimeout() {
  echo("onTimeout(): i =" SPC i);
}

function test() {
  echo("test(): i =" SPC i);
} 


Returns:

onCreated(): i = 34 temp.i= 
test(): i = 34
onTimeout(): i = 34