There are several types of coding, you need to use all of them

1. Masterpiece, code that written to be a poet, small, efficient, readable, with not so much comments (its not a tutorial)
2. Code for reading, to describe an algorithm, to publish it, well, now you can comment each line,
3. Optimised for speed, this could be hard to be readable by an non - assembly programmer, but it is acceptable,
4. Dirty fast, code that written to get some results before you decide what solution you will use, this must removed, and should be redesigned and rewritten, in the same day if is that possible,
5. Scripts, simple code, in script language or not, to do few things, not to be used in a product, still it must be clear and readable

What is good and what is bad practice depended by the project

Example: In a scientific application to display cannot compute in case of division by zero is something normal. In a financial application you must be lunatic to display I cant divide my stock by zero sales, you have always has to display 0 items.

In all cases, to crash and exit because of a division by zero interrupt, it is unacceptable.

Object-Oriented Programming is good, only if needed

Actually it could be a great waste of resources and time if it is used when it is not needed; but it can be a marvellous if really needed classes in that part of your project. C++ is my primary computer language and I wrote many projects in this language.

Linus, when asked to write the kernel in C++, was upset not with the C++ as language but with the C++ programmers. C++ is C with extensions, you can write ANSI C of 1989 your whole project but using C++ compiler. So, what was wrong?

TODO: this is big subject...

There are not bad languages

Every language created to serve a role. You select your tool by what your project needs and how capable you are to work in low-level if need to.

Comparing Pascal and C is something classic. Pascal is a much better language to describe any algorithm and it can do almost anything. C created to be a cross-platform assembly, and is successful in it. It leaves the programmer free to do what he wants. This is very dangerous for most developers, but not for system developers.

I never suggest C or C ++ to developers without experience in Assembly.

Use exceptions only when need to

MessageBox() errors are very annoying thing. Try to inform the user with a static label, or something similar; you know mister, I am not yet ready to complete the calculations.

In case of exceptions, put in your mind, that you are the user. Do you want to see a message-box instead of return an error code?

A good application is the application that does what user wants in the way he wants. Whatever you learned in university is good for university, not for the market, not for you as user.

Comments & Names

Always document any function or method you wrote. It would be the first thing I would say if I had to hire you. For better documentation, use comments when you change the processing block within the routines. Also, always document the exits, the reader must be see that there is an exit and know why it is leaving… When you document code, you must know that probably you will need to read this after a few years.

Poly polyUnion(Poly &a, Poly &b)
{
	...
	// Find the crosses between polygons by check
	// the polygon A in clock-wise direction
	...
	// Check the result polygon for holes
	...
	if ( nHoles )
		return Poly();	// holes found,
						// return an empty polygon
	...
}

Use clear names of functions, to explain what it does; by repeating the same naming style for all of your code you can shrink the functions-names and still remain well readable.

class ... {
	void iset(int v);
	void fset(float v);
	void sset(const char *v);
	};

Example: If you use this style in all your project's code, no one ask you what the i means nor the v.

Always initialise local variables on block's begin

Always initialise local variables on block's begin, right up before use them.

count = sizeof(array);
while ( count ) {
	...
	count --;
	}

Need I to explain why?

Avoid expressions or function calls on loops

Avoid expressions or function calls on loops. Use local variables instead, to increase the speed and avoid bugs since parameters of the expression may change.

count = list.count();
for ( int i = 0; i < count; i ++ )
	...

Use multiplication rather than division

Use multiplication rather than division where it is possible. It's faster and safer.

Pass large parameters by reference

Passing parameters by value stores and copies in the stack the whole thing. So, use pointers (by-reference) for large structures or arrays.

Avoid GC (Garbage Collector)

Just try to close what you open, is so simple. Garbage collectors promises to solve you the problem which actually never I had, well never I didn't solved in few hours, and creates two more problems: a) slower execution and b) huge memory fragmentation. Even if you use garbage collector, find a way to disable it for specific code modules. You have the power to control when to allocate and when to free large blocks of memory; use it. Even better, when you really need GC you can implement one of your own, for your own lists, it is so, so, so easy in C++. I wrote a few, the first one was with paging memory (virtual memory), and it was the time I finished high school.

Use UNIX® ways

After so many years, UNIX was the the school of all others OSes; even today, more than ever, it is leading the way on programming. So, use the solutions that would you prefer in Unix environment.

Prefer PHP instead of Python

Really, do you believe that you can implement an application in Python? Three kind of programs I don't allow to be used in my systems, a) Java applications, b) Python applications and c) JS-related anything. I didn't mention VB (Visual BASIC), because it's been dead for a long time (thanks Darwin!).

When scripting comes in case, prefer PHP, solid environment, same style as the most languages, easy as BASIC, faster than Python and the same - if not more - powerful.

Prefer SLang instead of LUA

Need embed a language? Try SLang, not LUA. Faster, mature, complete and steady. I have to mention that it has a more conventional syntax. LUA is too small and slow to compare.

http://www.jedsoft.org/slang

Avoid Hungarian notation

Avoid Hungarian notation at any cost,

1. because of * and the [l]p[p][sz] prefix in C, there is no fun at all to read lpX instead of *x,
2. because of block local variables, you offer nothing but confusion,
3. because a variable can change type, but does not change meaning,
4. because a function can change return type, but does not change meaning,
5. because you read the type in function's declaration (which is also your help-text in your IDE) not in the function's name…
6. because Microsoft using it, this company created the XML, they preferred <param name="x" value="1" /> instead of x=1.

Avoid to use XML

1. because in end of 50s, you could write this: AREA=SQRTF(S*(S-FLOATF(IA))*(S-FLOATF(IB))*(S-FLOATF(IC))), in FORTRAN II, in punched cards, and compile it, and run it, in a machine with 4K words of magnetic drum memory, at 12K FLOPS (8087 runs 50K FLOPS),
2. because a Tiny BASIC implementation could cost you few hours of coding,
3. because I wrote Tiny BASIC implementation as an example for SmallBASIC (which also I wrote) in 500 lines, with help lines, flow control statements, comments and has interactive mode too,
4. because quoted strings is also ancient invention,
5. because slashed characters, well used at least from 1971 and requires also a few bytes code,
6. because AWK created in 1977,
7. because a CSV file can stores tabular data (numbers and text) in plain text and was used in FORTRAN77, etc

Simple parser

PROGRAM SimpleParser;
VAR	TextFileHandle : TextFile;
	buffer, keyword, value : String;
	index, buflen : Integer;
BEGIN
	Assign(TextFileHandle, 'data-filename.txt');
	Reset(TextFileHandle);
	WHILE NOT EOF(TextFileHandle) DO BEGIN
		ReadLn(TextFileHandle, buffer);
		index := Pos(Char('='), buffer);
		IF index > 0 THEN BEGIN
			buflen  := Length(buffer);
			keyword := Trim(Copy(buffer, 1, index - 1));
			value   := Trim(Copy(buffer, index + 1, buflen));
			WriteLn('Keyword found: ',
				keyword, ' with value ''', value, '''')
			END;
		END;
	Close(TextFileHandle)
END.

I didn't even compile it... so easy...

Later I add a load-configuration function in C, in a known project... so here it is: load-config.txt.

Always use TABs, hard TABs, ASCII 9, ^I

I know a lot of you are fall in love with spaces but spaces does not removed or increased by pressing just a key, even worst you cant move by using just a key.

There are a few that does not indent their code at all; I suggest that they to be executed in a public square…

You can't read code without proper tabbing; even worse you'll understand wrongly what it is typed for example thinking that variable in the beginning of the line, should be a global variable...

Use any coding style you like

Use any coding style you like; especially the one you read the blocks more easily and correctly. I get bored with such discussions; the correct implementation (black-box style) of modules/classes is important. I use the Ratliff style (a relative of the Whitesmiths style) - my past in PASCAL is obvious - but I have no problem with most styles. I suggest you avoid the lisp style, since you will lose the right-braces.