What are the most commonly use web development policies in software companies?

Question

Having the best forum website among developers, I think I will find a very good consensus of what policies and best practices make good coding. I will put some of them here, so I give the idea, but I will like to hear your opinion and the votes will probably be the judge of the best policies around.

• Specific Indentation for coding between development teams
• Specific comments before each method, before each variable declaration
• Naming conventions, camel case or any other.
• In HTML commenting after each container tag.
• In CSS, using each declaration only once.

You get the idea. I will like to know what things company ask us to do, and what of those really work to obtain maintainable and beautiful code.

Answer 1

I would focus any policies around development practices rather than code formatting. Some examples are:

• Always use parameterized SQL queries. Never concatenate user input into a query.
• Keep HTML, CSS and JavaScript in separate files.
• Use jslint or an equivalent tool every time you commit code.
• Pick an HTML standard (such as HTML 4.01 strict). All HTML must validate.

And don’t be a policy-nazi. Sometimes rules have to be broken—but there should be a very good reason for doing so.

Answer 2

(For PHP projects, at least -- note that PHP is open-source and has an important community ; so, many things are quite driven by what's done in the community)

First of all, when using a Framework on a project (ie, always), we try to stick to its policy, if clearly defined (it's the case for Zend Framework, at least) : it ensures anyone who will come to work on this project can :

• find a definition of the standard
• re-use it on any other projects that use the same framework
  • even when going to another company, or working for another client
  • or when coming from another company ;-)

Considering we are only using between 3 and 5 frameworks for PHP projects in the company I work for, and that many rules defined in their standards are the same, it's not a real problem.

Same applies if coding inside/arround some kind of CMS, for instance, of course.

When not using a specific framework, we try to stick to a common set of rules widely accepted amongst the PHP community : same way, it ensure those rules are well-known (even by new-comers to our company), easy to find, and that many people did try them and enhanced them.

About comments, there is one tool that is well-used in PHP : phpDocumentor (about the same thing as javadoc) ; it defines a standard -- this one is the de-facto standard, as there is no other tool that is used that much.

About specific comment-tags :

• we always use @param / @return : they are integrated in the IDE, to provide type-hinting, so are useful
• else, we don't use much : a couple of lines to say what the method does if it's not obvious ; a couple of lines if a difficult algorithm is used.

Camel-case or other : we stick to what is common amongst both the PHP community and frameworks :

this_is_a_function

And

ThisIsAClassName

And

thisIsAMethodName

In HTML : as much as possible, we don't use HTML comments, because they are sent to the browser :

• means bigger pages (ok, not that much)
• means giving away informations the user doesn't need

If possible, we use comments from the templating-engine.

In CSS : we comment when needed ; more important thing is to use several small CSS files, quite specific (even if using a merge-tool during the build process)

But, maybe more important than all this : we try to use "clean" code, with small methods that only do a small "unit" thing, with self-describing names and all

It doesn't do magic, but it helps understanding the code... And, also, testing it, re-using it, ...

Also, as Nate said : these are mostly guidelines -- except if specifically required by a client... In which case you have to put some automatic tool (In your build process, for instance) to verify they are followed by the letter.

Answer 3

• Code doesn't exist if it's not under version control. More specifically, NOTHING is on a production server unless it's committed to the repository.
• If a project presents an opportunity to refactor old code, take that opportunity.
• Maintain a wiki or similar to document procedures, standards and use of library code (when such documentation is too much for code comments)