These functions often stretch well over several hundred lines of code, and often have some form of action in the title, like "doMyStuff", or "doComplicatedSequence". Also, make sure you name the God functions or methods in camel case, so it is very clear you never bothered to read the Python Style Guide: PEP 8.
Extra Credit:
* Add huge blocks of commented code and mix them in the middle.
* Add comments in the doc string or anywhere, that say, this is "magic", or "bad" and needs to be rewritten.
2. Never return anything in a function, especially not some type of value that could demonstrate your function succeeded or failed.
This makes your code almost impossible to test and makes it clear you think programming is "magic". After all, who cares if a function does what you wanted?
3. Never write a test...EVER.
Claim testing is impossible where you work because it is different. Make up excuses like, "I am used to other people testing my code" (This one sounds especially good if your a former .NET developer.) If you really want to go all the way, don't even bother looking up how to write a unit test. Convince yourself it is impossibly complicated and not worthwhile and that people won't notice.
4. Call Perl from Python
This is an oldie but a goodie, but a lot of bad programmers don't realize they can make their Python code even worse, if they embed a bunch of untested, legacy, Perl code in it. There is a Perl/Python module that makes this a snap.
Extra Credit:
* Call a nest of Perl regular expressions from Python instead of doing a doing something like:
if "string" in variable:
* Brag that you called Perl from Python because it was "quicker" to experienced Python programmers.
5. Screw Control Flow
If you can write a few statements, then mix in some functions, then maybe define a class, then write more statements, you have "screwed" Control Flow successfully. Something like below is a good starting point:
#!/usr/bin/env python
print "My Script is running"
import os
if os.path.exists("/tmp"):
def myfunc():
x = 4
return x
class Foo(object):
y = 1
f = Foo()
print f.y + myfunc()
6. Abuse conditional logic to the point that you double or even triple an "unmaintainable" Cyclomatic Complexity Score of 50.
Nothing says I suck at Python better, then writing nested if/else statements from here to the moon. How you can tell you sucked enough? Easy, just run the cyclomatic complexity metric from PyMetrics, and if your function or method doesn't yet rate a 50, which is basically unmaintainable/untestable code, then keep trying! If you can double or even triple that to say 100 or 150, you will put the capital "S" in Suck!
7. Use sleep statements like Holy Water.
If you write something sketchy and want some extra "luck", then sprinkle in a few time.sleep statements. If you use them randomly and arbitrarily it will get the point across in short order, that you don't know what the hell that piece of code does and you're just guessing! Awesome!
8. Initiate the same logic more then once, "just to be sure".
Often when you're writing some really crappy code, you're lucky if you know what it is doing. If you can write a function that does something that makes you feel emotionally safe and then call it for luck a few times...bingo...you win!
Something like this is always a gold standard:
count = 0
for i in range(5):
if os.path.exists("/tmp"):
print "bingo"
def foo():
print "stuff"
if os.path.exists("/tmp"):
import sys
sys.exit(1)
9. Write Library Code that does a sys.exit(0) on an exception.
If you can write an API that catches all exceptions and then does a silent sys.exit(0), you will really piss someone off that uses you're code and demonstrate you're a hack.
Something like this is a good start:
def api_entry_point():
try:
obj.method()
except:
#lets not bother the developer with this exception. He should quit out immediately!
import sys
sys.exit(0)
10. Reimplement the Python Standard Library in every piece of code you write.
Show you really don't give a rat's ass about learning the language. Reimplement arg parsing,
config parsing, the subprocess module and more.
Summary
If you can do just a couple of these things in every piece of code you write, you are well on your way to writing bad python code! Stay tuned for part II.