Up Yours Truly

A fairy tale about software development

Archive for the ‘Best Practices’ Category

10 Tips on How To Code Like an Asshole

leave a comment »

Have you noticed that lots of programmers are trying to express themselves through their code to show how nasty they are? They enjoy the idea that years later some lucky guy like you will have to dig into their mess and say something like “Shit, this dude must be a tough mother fucker, he would probably beat the hell out of my in the bar. Even his code looks so nasty!”. Some programming languages actually help you to achieve this result by providing features like case insensitive code, chance to use Unicode in programing entity names, all the possible occurances of under_score_crap, Asshole_Case, Super_Fucking_AssHole.SUPERCONVENTIONALSTUFF and similar sightings in core libraries… Undoubtly, the more asshole features language can offer – the more popular the it gets. To name a few sharks: Oracle PL/SQL, PHP, Perl, Ruby, VB. Any of these can help you express how much of an asshole you are! Now, the tips for those who want to express themselves:

Admit it!

1. Screw the code conventions. Be original – be yourself. Mix spaces with tabs, mix CamelCase with Asshole_Case and CHUCKNORRISCASE. 80 char line limit is for pussies. Discover your own special style!

2. Comments are for losers. Great code speaks for itself. Never comment any code, just make sure to add a header with Author name and email so future readers will know whom to send job offers, fan mail or love letters to.

3. Experienced software developers know what code reuse means. Show that you are are a master of reuse by copy-pasting pieces of code from other projects, same project, same file, various snippets from the internet. Use Google’s “I’m feeling lucky” button and take the first code example that appears. Make sure you modify it as little as possible.

4. Blogs are the source of knowledge, so make sure to use all the new open source libraries that were out within the last couple of months. Time tested stuff is just a legacy.

5. Don’t give a fuck about resources. Computers are so fast these days.

6. The longer your methods are, the longer your penis is. Show how long is yours!

7. A Cyclomatic Complexity check shows how sophisticated and smart the author is, so make sure your CC is high enough. 25 is a dead minimum. Besides, you can do cool stuff with nested code.

8. Keep in mind that programming is a “write and forget” process. Do things quick and dirty. Your productivity will be so high that you will mostly get promoted.

9. Teamwork is a race. Be the winner – be sure to commit your changes before your teammates do. Then run home and let other losers work overtime to resolve the conflicts and enjoy your beautiful code.

10. Always argue with those who try to prove that you are doing something wrong. Only losers and pussies agree that they can be wrong. Father knows best!

Now you can code like an asshole too!

Advertisements

Written by Ken Benchmark Jr.

February 21, 2008 at 12:58 pm

Posted in Best Practices

Tagged with , ,

The Stairs of Death

with one comment

Today we’ll have a small Oracle workshop sponsored by one of our Oracle Certified Associates:

Oracle Associate Logo

Have you ever seen a huge, and I mean huge piece of code full of nested blocks? I bet you did. The most encouraging thing that could happen is to see something like this in your editor at the end:

5687:                END IF;  -- You can now hang yourself here.
5688:              END LOOP;  --                               |
5689:            END IF;      --                               |
5690:          END IF;        --                               O
5691:        END IF;          --                              /|\
5692:      END LOOP;          --                              / \
5693:    END IF;
5694:  END IF;
5695:END;

This is called The Stairs of Death. It’s the best way to express your love to those who some day will have to continue the development of this magnificent programming gem. You can imagine climbing up there and hanging yourself.

Such and similar ASCII (pronounced Ass-Key) art is usually found in code of Sergey Klepalov.

Written by Ken Benchmark Jr.

January 29, 2008 at 12:17 pm

Guaranteed Execution

leave a comment »

Dear Reader. Today is the opening of the Best Practices section and I am proud to introduce to you the first Design Pattern that was recently discovered by one of my beloved colleagues. Without further ado, here it is:

Pattern Name and Classification:
Guaranteed Execution

Discovered by: Willy Benton

Level of Complexity: Intermediate

Intent: Provides a fail safe way of executing a code block with 100% certainty.

Also Known As: Surefire Block, 100% Execution, Execute It For Real

Motivation (Forces): Imagine you have a code block that plays a very important role in your application. You wouldn’t want that block to be accidentally skipped by the compiler or interpreter, or by CPU in run time. You have to take precautions. Guaranteed Execution is the best practice in such occasions.

Applicability: Can be used in any programming language which supports If / Else constraints. Although, we suggest extensive use of Guaranteed Execution design pattern in PHP, Perl and Ruby to make sure your mission critical applications will work as expected.

Structure:

Guaranteed Execution Design Pattern

Participants:

Compiler / Interpreter / CPU – a thing that processes the code (the author is not quite sure which one is it).
Critical Code Block – a block of code which MUST be executed by any means necessary.
The Lure – If / Else statement that attracts the attention of Compiler / Interpreter / CPU therefore lures it into execution of the Critical Code Block.

Collaboration: Either compiler, interpreter or CPU is doing it’s usual daily job – computing and stuff. One of them notices The Lure – an If / Else statement, and says “Shit, this must be important, I’d better go execute it”. If / Else statement traps the Compiler / Interpreter / CPU and forces it to execute the Critical Code Block. Job well done!

Consequences: Your mission critical application will work as expected. No trade offs or side effects whatsoever as If / Else statements work really fast (“I am sure If / Else statements work as fast as your eye blinks” – W. Benton).

Implementation: The implementation is straightforward. It should get clear after reading the Sample Code.

Sample Code:


<!-- the usual HTML here -->

<?php

//Compiler / Interpreter / CPU hidden here somewhere

$a = 1;
$b = 2;

//The Lure
if (!is_empty($a + $b / 10032)) {
    //Critical Code Block
    $application_safe = true;
    $critical = "executed";
} else {
    //Critical Code Block
    $application_safe = true;
    $critical = "executed";
}
?>

<!-- back to the usual HTML here -->

Known Uses: Number of mission critical applications of SHIT Inc. that cannot be disclosed.

Related Patterns: Soon to come (wait for the updates).

Written by Ken Benchmark Jr.

January 27, 2008 at 9:16 am