Cum sa scrii cod nementenabil – demential

Pe StackOverflow.com citeam (varianta beta – cea oficiala va iesi pe la mijlocul lui Septembrie (2008)) despre ce articole considera cititorii drept cele mai utile pentru cariera lor de programatori. Ei bine am dat de un articol recomandat care sincer mi s-a parut demential!

How To Write Unmaintainable Code scris de Roedy Green.

Este un contraexemplu lung si bine structurat, acopera cam toate prostiile pe care le fac voit sau nevoit programatorii mediocrii si cei prosti. Este o combinatie excelenta intre umor si disciplinare.

In principiu va las sa cititi articolul original, la adresa de mai sus insa va voi spicui cateva fragmente ce m-au facut sa rad ca prostu’ in fata monitorului pe la 4 dimineata cand il citeam :

O mica introducere asupra scopului lucrarii :

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn’t be able to maintain the code!

Apoi ajungem la detalii mai concrete :

Be Abstract
In naming functions and variables, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method.

Ne plimbam prin notiuni mai abstracte iar :

Programmers are lulled into complacency by conventions. By every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass.
You might get the idea that every language feature makes code unmaintainable – not so, only if properly misused.

Conventiile de notare par sa fie un lait-motiv :

Bedazzling Names
Choose variable names with irrelevant emotional connotation. e.g.:
marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they’re trying to think about.

Reuse of Global Names as Private
Declare a global array in module A, and a private one of the same name in the header file for module B, so that it appears that it’s the global array you are using in module B, but it isn’t. Make no reference in the comments to this duplication.

O chestie pentru care mi s-ar parea normal sa faci puscarie :

Overload new
Overload the „new” operator – much more dangerous than overloading the +-/*. This can cause total havoc if overloaded to do something different from it’s original function (but vital to the object’s function so it’s very difficult to change). This should ensure users trying to create a dynamic instance get really stumped. You can combine this with the case sensitivity trickalso have a member function, and variable called „New”.

O perla permanent valabila :

Clone & Modify
In the name of efficiency, use cut/paste/clone/modify. This works much faster than using many small reusable modules. This is especially useful in shops that measure your progress by the number of lines of code you’ve written.

Traznai nemaiauzite (de mine macar) :

Use Three Dimensional Arrays
Lots of them. Move data between the arrays in convoluted ways, say, filling the columns in arrayB with the rows from arrayA. Doing it with an offset of 1, for no apparent reason, is a nice touch. Makes the maintenance programmer nervous.

Daca nici acum nu v-am convins sa cititi intreg articolul atunci va pot asigura ca ce am pus aici nu e nici macar 5% din ce puteti gasi acolo.