Guidelines

Always use descriptive variable names. Using acronyms for variable names is frowned upon in this establishment. You have to realize other people aren't reading your files from top to bottom. They're following stack traces to line numbers. The less we have to decipher, the better. Don't get uber verbose, that can be equally confusing.

Use newlines to seperate logical blocks of code. Newlines help guide your eyes. But don't abuse newlines! Too many newlines and nothing stand out. Use your best judgement, but readability is always priority.

Learn to use inheritance. If you're copy/pasting templates, you're doing it wrong.

Comment the end of blocks (closing html tags, closing parens, closing brackets) to help signify it's end.

Learn git. Use git.

Conventions

Use spaces instead of tabs, and set your tab size to 4 spaces.

Classes in pretty much all languages are Pascal case.

php

Use Camel case for class properties and methods. Use snake_case for normal variables and static method names.

Set tabs to always be spaces, and use 2 spaces per indent.

Use the Allman style for curly braces for class and function definitions. The curly brace should be on the next line by itself.

Sample

class TestThing
{
    public $objectProperty;

    public function methodName()
    {
        ...
    } // End methodName

    public static function method_name()
    {
        ...
    } // End method_name

} // End TestThing

function function_name( $argument = null )
{
    ...
} // End function_name

$variable_name = new TestThing(); //Non-object and objects
        

symfony

Projects should be broken into logical modules. Typically a main nav item and it's subnav items can be made into a module. Module names should be camel cased. Pretty much everything can be containted in a single app (which by convention is named frontend).

Sample

// Put something here...

Ruby on Rails

# Put something here...

CSS

Use the minimalistic approach with stylesheets. Styles should be on one line, separated by spaces.

• Do not specify a font family for body text. Instead, just use serif or sans-serif.
• Use inline styles as never as possible.

Sample

body {font-family: sans-serif; background: #000;}
h2, h2, h2, h2 {font-weight: bold; text-transform: capitalize;}
h2 {font-size: 1.6em;}
        

Objective-C

Typically custom classes (which aren't view controllers) and protocols begin with a two or three letter abbreviation of the organization to tip your hat to NeXTSTEP.

Use Pascal case for classes. Use Pascal case for constants and prefix with the a two or three letter abbreviation. Underscores for instance variables

Set tabs to always be spaces, and use 4 spaces per indent. (Xcode defaults)

Note: Cocoapods recommends a three letter abbreviation to further prevent the collision of class names.

Sample

Header

#import 

#define INTestThingDebug 1
@interface INTestThing : NSObject

@property (nonatomic, strong) NSArray *myArray;

+ (id)initWithTestThing:(NSString *)thing;

- (BOOL)doSomething;

@end

Implementation

#import "INTestThing.h"

@interface INTestThing()
@end

@implementation INTestThing

@synthesize myArray = _myArray;

+ (id)initWithTestThing:(NSString *)thing
{
    // designated initializer
    // for sample and correctness purposes return nil
    return nil;
}

- (BOOL)doSomething
{
    BOOL ret = NO;
    // do something here
    return ret;
}

@end
        

Git

Projects should have a prod (or master), dev, and staging branches at the minimum.

New branches should be created to add a specific feature/module or refactoring. Submodules may be used to separate components of an application, for example, base actions, models, etc.