Hæ allir hakkarar :-)

Þar sem hefur verið töluvert mikið rætt um ungverkan rithátt, fannst mér vera rétt að tala næst um “Coding standards,”
ekki síst vegna þess að sumir virðast vera dálítið “lost” í þessu öllu saman, sem er í sjálfu sér ekki skrítið.

Fyrir um 2 árum vann ég fyrir amerískt fyritæki sem ég kalla X og tók þar þátt í verkefni sem var yfir $20 mill. verkefni, hér er staðallinn sem þeir settu fram, umhverfið er WebObjects og forritunarmálið er Objective C, en staðallinn er það abstrakt að hægt er að laga hann að nánast öllum forritunarmálum.

Coding Standards

1) No script coding in WebObjects. All code should be objects.

2) No compiler warnings. #warnings are okay. Placing framework
#imports before local #imports will remove most of the warnings.

3) Documentation (more on this when we decide how we want code
documented). In it's simplest form, good Objective-C code should
read like english and be easy to understand.

4) Proper log information included with cvs commits.

5) Code checked in to cvs *must* compile and run.

6) If code is to be used more than once than it should be written
to be reusable (such as components in WOF).

7) All code should be “pushed as low as it can go”, ie, if it's
reusable for more than one app than it should be pushed down
into a framework (if one exists).

8) Variable/table names should be in english, simple, make sense
and not be abbreviated. Entity instance variables should match
the table name.

9) No black-magic in your code. Keep it simple. If you cannot
explain it, don't code it.

10) No extensions to Apples run-time code. In general, if you run
into an Apple bug try to find another way to code the requirement
instead of overriding Apple framework methods or extending runtime
code that will break with Apple's next release.

11) All code should run properly under OS X and PDO Solaris.

12) No special environment variables should be needed to build
the code.

13) No special tools should be needed to build the code (perl, etc.).

14) Code should not be so “clever” in performing a task that it
cannot be easily extended or modified.

15) Code should only be checked in when authorized by the repository
gatekeeper.

16) Code should not have any external dependencies on 3rd party
frameworks or special bundles for ProjectBuilder, EOModeler,
WOBuilder, etc.

17) No memory leaks or memory exceptions. Variables should not be
released unless they have been retained. Components referring to
session variables should either always reference the variable in
the session object or retain/release it using a local ivar.

19) All insertions, deletions, modifications to the database should
use our common code (currently half built). All editingContext
saves MUST perform data validations on varchar lengths, integers
mins and maxs, variables that aren't allowed to be NULL and any other
variable or relationship that must be set. Do not expect EOF or
Sybase to validate for you. We want/need a robust and user friendly
system and writing to the DB is our most important task. The DB is
the lifeblood of the company, we must protect it the best we can.

20) Code must be tested before it is checked in to CVS. Does it compile
with no warnings, fulfill the use case, retain/release memory
properly, handle data validation, handle exceptions properly, documented?

21) Any changes needed to the DB schema should be submitted to the
repository gatekeeper at time of check in.

22) Understand the reasoning behind the code your writing. Our technical
team does not exist to write cool code, we exist to satify the
marketing, management and technical needs of X. Solving the
intended goal of the requirement in an efficient, robust, timely and
scalable manner is our most important task.