The art of Unmaintainable Code
How to write unmaintainable code. Ensure a job for life ;-)
This is a satire for those who will miss the end. At the same time, I have met developers who have perfected the art of unmaintainable code over 25 years. One wrote, 'if code runs on Silicon Graphics hardware do ...' in 2019, though Silicon graphics went bankrupt in 2009, and zero lines of code ran on SGI's hardware in over a decade at that shop. So, this matters. Do the precise opposite of every detail here. Enjoy the ride.
Unmaintainable code comes from five core practices:
- Naming: use single-letters, typos and a baby name book
- Coding style: camouflage, obfuscate, ‘optimize’, avoid consistency
- Code structure: copy-paste, break encapsulation, use global/static members, wrap unnecessarily
- Documentation: lie, state the obvious, leave placeholders
- Languages & Formats: mix them, invent your own
Are you tired of colleagues or managers easily understanding and maintaining your code?
Do you wish to ensure job security by creating code so convoluted and difficult to comprehend that no one else could possibly maintain it? Look no further than the tips from the masters on how to write unmaintainable code. In this blog post, we'll take a look at the principles and techniques to create code that will have even the most seasoned programmers scratching their heads for years to come.
From intentionally violating conventions to hiding the big picture, we'll cover it all. So, if you're ready to guarantee yourself a lifetime of employment, let's dive in.
Naming
"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less."
Are you ready to dive into the dark arts of code obfuscation?
In this section of our ̶s̶a̶t̶i̶r̶i̶c̶a̶l̶ blog post, we will guide you through the mysterious labyrinth of baffling variable and method naming practices that will leave your colleagues scratching their heads in utter confusion. From single letter variables to creative misspellings, we've got it all covered. So, buckle up, and let's embark on this mischievous journey to explore the twisted world of unmaintainable code through the power of bewildering naming conventions. Remember, this is all in good fun, and our ultimate aim is to underscore the significance of using clear, consistent, and maintainable naming practices in real-world programming.
While compilers may not care about naming conventions, the human developers who will maintain the code certainly do. With the power to confound maintenance programmers at your fingertips, thanks to your variable and method naming skills, the possibilities for writing obfuscated code are endless!
Naming:
Despite their insignificance to the compiler, they provide ample opportunity to confound the maintenance programmer.
int x; // This is boring
int fred; // This is more interesting
int qwert; // This is even better
int jklmnop; // Good luck guessing what this is for
int i1; // This looks like a simple loop index, but is actually a critical global variableSingle Letter Variable Names:
Craft code chaos with vague variables like a, b, and c. Avoid predictable indexing variables like i, j, and k, opting instead for ii, jj, and kk. Anyone suggesting otherwise risks the wrath of the Inquisition.
for (int i = 0; i < n; ++i) {
for (int j = 0; j < n; ++j) {
a[i][j] = i + j;
}
}
Creative Miss-spelling:
To make your code a mystery to all but you, try misspelling descriptive variable and function names. Alternate between correct and incorrect spellings, as in SetPintleOpening and SetPintalClosing, to confound grep and IDE search techniques. And for an extra dash of international intrigue, mix up spellings of words like "tory" or "tori" depending on the theatre/theater. The result is a truly amazing code obfuscation technique.
int numbr_of_items = 10; // Wait, is that supposed to be "number"?
void show_messgae(); // Is this a typo or intentional misspelling?
Be Abstract:
Confuse and baffle maintenance programmers by using abstract terms like "it," "data," and "stuff" in function and variable names. Add some digits and mix in words like "routine," "perform," and "handle" for extra obscurity.
void do_stuff(int x, int y, int z) {
// This function does...something with x, y, and z
}
void perform_operation(int a, int b, int c) {
// This function performs...some sort of operation on a, b, and c
}
A.C.R.O.N.Y.M.S.:
Code like a true warrior by using acronyms without explanations. Let the weak and feeble-minded be left behind in confusion, while you stride ahead confidently, wielding the power of coded abbreviations.
int gdt; // What does that stand for? Who knows!
void rpc(); // No need to spell it out, right?
Thesaurus Surrogatisation:
To spice up your coding routine, explore the vast depths of thesaurus entries to find alternative words for common actions, such as "display," "show," and "present." Even if the differences are subtle or nonexistent, hint at some supposed distinction to confound and intrigue your fellow coders. But when dealing with two similar functions that have a crucial difference, always use the same word to describe both, even if it causes confusion. For example, use "print" to mean "write to a file," "put ink on paper," and "display on the screen." And if anyone suggests creating a glossary to define the project's special vocabulary, reject the notion outright. Such a move would violate the principle of information hiding and demonstrate unprofessionalism. So keep your coding enigmatic, and let the mystery keep your colleagues on their toes.
void present_data(); // Is this the same as "display_data" or something different?
void exhibit_data(); // Now we're really confusing things
Use Plural Forms From Other Languages:
Ye scurvy dog, make yer code spicy with exotic languages like Esperanto, Klingon, and Hobbitese. And don't forget to add an "oj" to yer Esperanto plurals, lest ye be accused of bein' a landlubber. With this code, ye be helpin' the cause of world peace, arr!
void appendi_data(); // Is this supposed to be "append_data"?
void updatei_statii(); // What is this, some kind of Latin plural?
CapiTaliSaTion:
Add some excitement to your code by randomly capitalizing letters within words, like "ComputeRasterHistoGram()." Have fun with it.
void coMPutE_ResulTs(); // This is just painful to read
Bedazzling Names:
To really mess with your reader's mind, choose variable names that evoke irrelevant emotional connotations.
#include <iostream>
#include <cmath>
int main() {
int unicorn = 5;
int rainbow = 10;
int sunshine = 20;
int mystic_forest = 30;
int dream = (unicorn + rainbow) * mystic_forest / sunshine;
std::cout << "The dream value is: " << dream << std::endl;
return 0;
}
Recycle Your Variables:
As a seasoned entrepreneur and coding mastermind, let me tell you about a truly devious trick to befuddle even the most astute developers. It's all about using scoping in the most confusing way possible. Take, for example, two global variables, A and B, and two functions, foo and bar. If you know that variable A will be regularly passed to foo and B to bar, switch things up by defining the functions as function foo(B) and function bar(A). This way, inside the functions, A will always be referred to as B and vice versa, creating a labyrinthine web of contradictory uses of the same names. With more functions and globals, the possibilities for confusion are truly endless. So go ahead, take your coding to the next level with this mind-bending technique.
#include <iostream>
int A = 10;
int B = 20;
void foo(int B) {
std::cout << "Inside foo(): A = " << B << ", B = " << A << std::endl;
}
void bar(int A) {
std::cout << "Inside bar(): A = " << B << ", B = " << A << std::endl;
}
int main() {
int A = 30;
int B = 40;
foo(B); // expects B to be passed, but inside foo() A will be referred to as B
bar(A); // expects A to be passed, but inside bar() B will be referred to as A
std::cout << "Inside main(): A = " << A << ", B = " << B << std::endl;
std::cout << "Global variables: A = " << ::A << ", B = " << ::B << std::endl;
return 0;
}
Åccented Letters:
Add accented characters to your variable names for some extra confusion. A simple tweak, like using an i-acute on the second "ínt" in a typedef struct, can throw off even the most experienced coders. It's the perfect way to keep your colleagues on their toes and add some extra spice to your code.
int dísplay_data; // Good luck typing that
void straße(); // Is this supposed to be "strasse"?
Underscore, a Friend Indeed:
Make use of underscores (_ and __) as identifiers in your code. Using underscores as the first character of an identifier in C++ is a great way to show your coding prowess. It will make your code more memorable and unique. Additionally, conflicts with standard library or implementation-defined names are just opportunities to show off your ability to work around limitations. So go ahead and embrace the underscore, make it your own, and watch as your colleagues marvel at your evil genius.
int _a; // This must be important, it has an underscore in front of it!
void __do_something(); // This function is extra special, it has two underscores!
_ and __ as variable names, a must do.
#include <iostream>
int main() {
int _ = 42;
std::cout << "The answer to the ultimate question of life, the universe, and everything is " << _ << std::endl;
double __ = 3.14;
std::cout << "Pi is approximately equal to " << __ << std::endl;
return 0;
}Mix Languages:
void printar_datos(); // Is this Spanish or something else?
void afficher_les_données(); // This looks like French, but who knows what it means?
Extended ASCII:
int ß = 42; // Is that supposed to be a "beta" or something else?
int ñ = 5; // This will be fun to type
Names From Other Languages:
void punkt_berechnen(); // Is this supposed to be "calculate_point"?
void matris_çarpımı(); // What language is this even in?
Reuse Your Variables
When scope rules allow it, reuse variable names that are unrelated. Additionally, use the same temporary variable for multiple, unrelated purposes to save stack space. For a more devious approach, try morphing the variable by assigning it a value at the beginning of a long method and then subtly changing its meaning later on, such as shifting from a 0-based coordinate to a 1-based coordinate without proper documentation.
#include <stdio.h>
void foo(int *tmp) {
printf("In foo: tmp = %d\n", tmp);
*tmp = 20; // update pointer value
}
void bar(int *tmp) {
printf("In bar: tmp = %d\n", tmp);
*tmp += 10; // update pointer value
}
void baz(int *tmp) {
printf("In baz: tmp = %d\n", tmp);
*tmp *= 2; // update pointer value
}
int main() {
int tmp = 0;
printf("In main: tmp = %d\n", tmp);
foo(&tmp);
printf("In main: tmp = %d\n", tmp);
bar(&tmp);
printf("In main: tmp = %d\n", tmp);
baz(&tmp);
printf("In main: tmp = %d\n", tmp);
return 0;
}or
#include <stdio.h>
void calculate(int x) {
int result = 0;
int i;
for (i = 0; i < x; i++) {
// Reuse result variable for two different calculations
result += i;
if (i % 2 == 0) {
result -= i;
}
}
// Reuse i variable to shift from 0-based to 1-based indexing
i = 1;
while (i <= x) {
printf("Element %d: %d\n", i, result + i);
i++;
}
}
int main() {
int num = 5;
calculate(num);
return 0;
}Make writing tests a fun and challenging experience by doing it in C and passing random variables between 10 different functions. This will force your fellow developers to carefully read every single line of code, ensuring that no sneaky bugs slip through the cracks. Plus, the thrill of the challenge will keep everyone on their toes and make testing feel like a game rather than a chore. So step up your testing game with this clever and exciting approach.
The "i" Trap:
float i = 3.14;
double n = 2.718;
for (int j = 0; j < 10; j++) {
i += n;
}
// This use of i for a non-integer variable can cause confusion and unexpected behavior
Are you tired of the same old boring variable names? Embrace the chaos and use "i" as your innermost loop variable. Not only will this cause confusion and unexpected behavior, but it will also make your code harder to debug. For an extra twist of evil, use "i" for non-integer variables and watch as your colleagues struggle to decipher your code. Remember, choosing meaningful variable names is overrated. Let the confusion begin!
Conventions Schmentions:
Wise man Linus Torvarlds suggests to: First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.
Do as he says! Thankfully, the compiler won't snitch when you break the rules. The aim is to create monikers that only differ slightly in casing. If you're obliged to adhere to capitalization norms, you can still rebel when there's room for interpretation – for instance, opt for both inputFilename and inputfileName. Devise your own bewilderingly convoluted naming protocols, then shame others for not abiding by them.
public class MyProgram {
private static final int nUMBeR_OF_ITems = 10;
private String inputFileName;
private int outputfileNumber;
public void pERForm_DATA_fUNCTion(int[] dATA) {
for (int i = 0; i < nUMBeR_OF_ITems; i++) {
dATA[i] += 1;
}
}
public void sET_input_FILENAME(String filename) {
this.inputFileName = filename;
}
public void sET_output_FILE_NUMBER(int fILEnUMber) {
this.outputfileNumber = fILEnUMber;
}
public void PROCESS() {
System.out.println("Processing...");
}
public static void main(String[] args) {
MyProgram mP = new MyProgram();
mP.sET_input_FILENAME("data.txt");
mP.sET_output_FILE_NUMBER(1);
int[] data = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
mP.pERForm_DATA_fUNCTion(data);
mP.PROCESS();
}
}
Reuse of Global Names as Private
Wow, let me tell you about this exciting example! We've got Module A with a global array defined at the top of the file, and then we've got Module B defined as a class with its own private array, also named "globalArray". But here's the kicker: the "doSomething()" method in Module B actually modifies the private array, but uses the name "globalArray" as if it were the global array from Module A. Are you still with me? Because this is where it gets really exciting. In the main function, we try to output the global array from Module A, but what do we see? It hasn't been modified by the method in Module B! Talk about a mind-bending twist. Make no reference in the comments to this duplication.
#include <iostream>
int globalArray[10];
class ModuleB {
private:
int globalArray[10]; // private array with same name as global array in Module A
public:
void doSomething() {
// use the private array in Module B, but pretend it's the global array from Module A
for (int i = 0; i < 10; i++) {
globalArray[i] = i * 2;
}
}
};
int main() {
ModuleB b;
b.doSomething();
// Oops, we've only modified the private array in Module B, not the global array in Module A
std::cout << "Global Array from Module A: ";
for (int i = 0; i < 10; i++) {
std::cout << globalArray[i] << " ";
}
std::cout << std::endl;
return 0;
}m_
One common naming convention in C++ is to prefix members with "m_". The intention is to distinguish them from methods, but it's easy to forget that "method" also begins with "m". So, instead of clarifying things, this convention can lead to more confusion. Similar goes for C# if there is the _ is for private members conversion, break it, break em.
class MyClass {
private:
int m_variable1;
int m_variable2;
public:
void m_method1() {
// do something
}
void m_method2() {
// do something else
}
};
int main() {
MyClass myClassObject;
myClassObject.m_variable1 = 5;
myClassObject.m_method1();
return 0;
}Hungarian Notation Revisited
As the nefarious Dr. Evil once revealed, a sly trick in Hungarian notation is to keep the variable name unchanged while changing its type. This is a common ploy in Windows apps, especially during the shift from Win16's WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32's WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam). The 'w' values might seem to indicate words, but they're really longs in disguise. The brilliance of this approach becomes even more apparent during the Win64 migration, where the parameters stretch to 64 bits, but the trusty 'w' and 'l' prefixes endure forevermore!
public class MyClass {
private int sCount; // Hungarian notation for "string count"
public void AddString(string s) {
sCount++; // Increment the "string count" variable
Console.WriteLine($"Added string {s} (count: {sCount})");
}
}
class Program {
static void Main(string[] args) {
MyClass myClassObject = new MyClass();
myClassObject.AddString("Hello");
myClassObject.AddString("World");
}
}
Obscure film references
Let's ditch plain old "blue", Lancelot'sFavouriteColour is fresh and new, Hex value $0204FB, that's the key, Monty Python fans know it's his color, you see!
With code that's witty and bright, We'll make our colleagues delight!
const int LancelotsFavouriteColour = 0x0204FB;
// ...
SetColor(LancelotsFavouriteColour);
Camouflage
The longer it takes for a bug to surface, the harder it is to find.
- Roedy Green
Get ready for an exhilarating journey into the world of code camouflage! In this section of our light-hearted blog post, we will delve into the devious techniques of writing more unmaintainable code by making use of confusion, misdirection, and subtle deception. From code that masquerades as comments to sneaky overloading of operators, we will uncover a plethora of methods designed to bamboozle even the most experienced developers.
One of the key abilities in writing unmaintainable code lies in the mastery of camouflage – the art of disguising things or presenting them in a deceptive manner. This often relies on exploiting the fact that compilers are better equipped than human eyes or text editors at discerning fine details. Below are some of the most effective techniques for achieving camouflage.
Code That Masquerades As Comments and Vice Versa
One technique for achieving camouflage in code is to include sections of code that are commented out, but that may not be immediately recognisable as such.
using System;
public class Program
{
public static void Main()
{
int[] array = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
int array_len = array.Length;
int total = 0;
for (int j = 0; j < array_len; j += 8)
{
total += array[j + 0];
total += array[j + 1];
total += array[j + 2];
total += array[j + 3]; /* Main body of
total += array[j + 4]; * loop is unrolled
total += array[j + 5]; * for greater speed.
total += array[j + 6]; */
total += array[j + 7];
}
Console.WriteLine("Total: " + total);
}
}
Would you be able to detect that three lines of code were commented out?
One of the primary benefits is that optimized code can run faster and more efficiently, resulting in reduced energy consumption by the hardware that executes it. When someone asks why you unroll for greater speed, simply reply that you care about the environment, and they should too.
Namespaces
In C, it is possible to define a struct and a union with the same name as they belong to different name spaces. In the example given, there is a typedef struct with the name snafu and a struct with the same name. This is legal in C, and highly recommended as it can lead to confusion and make the code harder to read and maintain.
typedef struct {
char* pTr;
size_t lEn;
} snafu;
struct snafu {
unsigned cNt;
char* pTr;
size_t lEn;
};
snafu a; // Declare a variable of type snafu
struct snafu b; // Declare a variable of type struct snafuIn this example, we have defined a typedef struct with the name snafu and a separate struct with the same name. This is possible in C because typedef struct and struct are separate name spaces in C. However, as I mentioned earlier, defining both with the same name can be confusing and make the code harder to read and maintain.
Look Busy
It's worth noting that this kind of code is not very useful in practice and can be confusing to readers.
#define fastcopy(x,y,z) /*xyz*/
#define reverselist(x) /*x*/
int main() {
int array1[] = {1, 2, 3, 4, 5};
int array2[5];
int size = 5;
fastcopy(array1, array2, size); // This line does nothing
reverselist(array1); // This line does nothing
return 0;
}
Arbitrary Names that Masquerade as Keywords
Alright, folks, listen up. When you're documentin' your code and you gotta come up with some random name for a file, don't go usin' somethin' too obvious like "Charlie.dat" or "Frodo.txt". No, no, no. You gotta use somethin' that sounds like it could be a reserved keyword, like "file". And when it comes to your examples, you gotta use arbitrary names that sound even more like reserved keywords, like "const", "input", "system", or "var".
And if you're really slick, you can even use actual reserved words as your arbitrary names, so your command processor or compiler will just straight-up reject 'em. Sure, it might leave your users confused as all hell, but you can play it off like you did it to help 'em learn the ropes. Just remember, the key to good documentation is confusion - for everyone else, at least.
#include <iostream>
int main() {
int bank = 1000;
int blank = 0;
int class_ = 1;
const int constant = 1234;
int input = 0;
int key = 5678;
int keyword = 999;
int kind = 123;
int output = 0;
int parameter = 4321;
int parm = 111;
int system = 777;
int type = 666;
int value = 888;
int var = 555;
int variable = 444;
std::cout << "bank: " << bank << std::endl;
std::cout << "blank: " << blank << std::endl;
// [...]
std::cout << "variable: " << variable << std::endl;
return 0;
}Code Names Must Not Match Screen Names
Trick your coworkers by giving variables names that have nothing to do with on-screen labels. For example, name a "Postal Code" variable as "zip" in the code. It's a guaranteed way to create confusion and chaos.
import java.util.Scanner;
public class Main {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.print("Enter your name: ");
String name = scanner.nextLine();
System.out.print("Enter your postal code: ");
String zip = scanner.nextLine();
// Do some processing with the user data
// Output the values of the variables
System.out.println("Name: " + name);
System.out.println("Postal code: " + zip);
}
}How to Hide Forbidden Globals
Global variables are considered "evil," so why not create a structure named "EverythingYoullEverNeed" to hold all those global variables? Then, have all functions take a pointer to this structure, which can be called a "handle" just to add to the confusion. And to really sell it, declare the structure statically so all the code will use the same copy. It's a sneaky way to make it look like you're not using global variables, even though you totally are.
#include <iostream>
// Define a structure to hold all the necessary data
struct EverythingYoullEverNeed {
int x;
int y;
float z;
// Add any other data members as needed
};
// Define a function that takes a pointer to the structure
void foo(EverythingYoullEverNeed* handle) {
// Access the data members through the handle pointer
std::cout << "x = " << handle->x << std::endl;
std::cout << "y = " << handle->y << std::endl;
std::cout << "z = " << handle->z << std::endl;
}
int main() {
// Declare a static instance of the structure
static EverythingYoullEverNeed data = {10, 20, 3.14};
// Pass a pointer to the structure to the function
foo(&data);
return 0;
}Conceal Your Code with Synonyms
Trick maintenance programmers by using synonyms defined with "#define" to hide instances of your variables. By creating clever aliases, you can make it difficult for others to track down your secrets. Have fun playing hide and seek with your code!
#define xxx global_var // in file std.h
#define xy_z xxx // in file ..\other\substd.h
#define local_var xy_z // in file ..\codestd\inst.hThrow maintenance programmers off their game by scattering variable aliases across multiple include-files and directories. Recycling names in every scope can also cause confusion for text searches. But watch out - SCIDs in the near future will make these tricks obsolete as editors become more sophisticated. Until then, have some wicked fun with your code!
// In file std.h
#define global_var myVar
// In file ..\other\substd.h
#define xy_z global_var
// In file ..\codestd\inst.h
#define local_var xy_z
#include <iostream>
using namespace std;
int main() {
int global_var = 1;
{
int xy_z = 2;
{
int local_var = 3;
// Access local variable
cout << "Local variable: " << local_var << endl;
}
// Access synonym variable
cout << "Synonym variable: " << xy_z << endl;
}
// Access global variable
cout << "Global variable: " << global_var << endl;
return 0;
}
Long Similar Variable Names
If you want to be cautious while still throwing off maintenance programmers, try using very long variable or class names that differ from each other by just one character. For example, use pairs like "swimmer" and "swimner." Exploit font limitations by using identifier pairs like "parselnt" and "parseInt," or "D0Calc" and "DOCalc." An "l" can easily masquerade as a "1," and "rn" can look like "m" in some fonts. For an extra layer of trickery, create variable names that differ only in case, like "HashTable" and "Hashtable." Get creative, but always play it safe.
using System;
public class MyClass {
private int swimmer = 0;
private int swimner = 1;
private int parselInt = 2;
private int parseInt = 3;
private int doCalc = 4;
private int docCalc = 5;
private string hashTable = "Hello";
private string hashtable = "World";
public void swirnrner() {
int sWimneR = swimner + swimmer;
Console.WriteLine("sWimneR: " + sWimneR);
int parsel1t = parselInt + parseInt;
Console.WriteLine("parsel1t: " + parsel1t);
int docalc = doCalc + docCalc;
Console.WriteLine("docalc: " + docalc);
Console.WriteLine("HashTable: " + hashTable);
Console.WriteLine("Hashtable: " + hashtable);
}
}
public class Program {
static void Main(string[] args) {
MyClass myClass = new MyClass();
myClass.swirnrner();
}
}Similar-Sounding Similar-Looking Variable Names
Why settle for just one variable name when you can have a whole slew of similar-sounding, similar-looking names to confound the memory-challenged? Try out names like xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z, and Xy_z - the possibilities are endless! These variables are designed to keep people who rely on sound or letter-spelling for memorization on their toes. With so many similar options, even the most careful programmer can slip up. So go ahead, have some fun with your variable names - just be prepared for some attention-grabbing confusion.
C++ Code Trickery: Overloading Library Functions
Pull a fast one on your fellow programmers. Use #define to overload library functions in C++. By doing so, you can make it seem like you're using a familiar library function, when in reality you're calling something entirely different. This devious tactic is perfect for those who want to keep their code hidden from prying eyes. So go ahead, give it a try - just be prepared to bask in the glory of your trickery!
#include <stdio.h>
#define strlen(x) my_strlen(x)
size_t my_strlen(const char* str) {
return 42;
}
int main() {
char* str = "Hello, world!";
size_t len = strlen(str); // This looks like the standard library function, but it's actually calling our custom implementation
// Do something with len
return 0;
}The Art of Overload Operator Obfuscation in C++
Why settle for boring old +,-,*,/ operators when you can turn them into something entirely different? Take a page out of Stroustrup's book and get cracking! When overloading +, make sure to give it a meaning that is totally different from regular addition. And why stop there? Elevate your obfuscation game by overloading the '!' operator to return an integer instead of inverting or negating. To get a logical value, use '! !', but be careful not to confuse it with the boolean 0 or 1 returned by the ! operator. And don't forget about the ~ bitwise logical negation operator! With these tricks up your sleeve, you'll be the master of overloading operator trickery.
class MyClass {
public:
MyClass(int value) : value(value) {}
// Overload + to add 10 to the value
MyClass operator+(int i) {
return MyClass(value + 10);
}
// Overload += to add i to the value
MyClass& operator+=(int i) {
value += i;
return *this;
}
private:
int value;
};
int main() {
MyClass a(5);
a = a + 5; // This adds 10 to a's value, because of the overloaded + operator
a += 5; // This adds 5 to a's value, because of the overloaded += operator
return 0;
}
#define
Get Sneaky with C++ Obfuscation Using #define take your C++ code to the next level of trickery with #define. By using lower case #define variables that masquerade as ordinary ones, you can confuse even the most astute programmer. Avoid parameters and use global #defines for ultimate control. Use #ifndef and #ifdef to make header files declare different things depending on how many times they are included, requiring multiple passes through CPP before compiling. This becomes especially wicked when one header is included in another. So go ahead, get sneaky with C++ obfuscation and watch as your fellow programmers scratch their heads in confusion.
#ifndef DONE
#ifdef TWICE
// Declare g() with a char* parameter on the third pass through CPP
void g(char* str);
#define DONE
#else // TWICE
#ifdef ONCE
// Declare g() with a void* parameter on the second pass through CPP
void g(void* str);
#define TWICE
#else // ONCE
// Declare g() with a std::string parameter on the first pass through CPP
void g(std::string str);
#define ONCE
#endif // ONCE
#endif // TWICE
#endif // DONE
Compiler Directives
Compiler directives were designed with the express purpose of making the same code behave completely differently. Turn the boolean short-circuiting directive on and off repeatedly and vigorously, as well as the long strings directive.
#include <iostream>
#define SHORT_CIRCUIT_OFF
int main() {
int a = 5;
int b = 0;
#ifdef SHORT_CIRCUIT_ON
if (b != 0 && a / b > 2) {
std::cout << "Short circuit on" << std::endl;
}
#else // SHORT_CIRCUIT_OFF
if (a / b > 2 && b != 0) {
std::cout << "Short circuit off" << std::endl;
}
#endif // SHORT_CIRCUIT_ON
return 0;
}
Documentation
Any fool can tell the truth, but it requires a man of some sense to know how to lie well.
- Samuel Butler (1835 - 1902)
In this section we delve into the various ways in which comments and documentation can be used to create unmaintainable code. We endorse these practices, understanding them can help developers recognize and implement pitfalls in their own work. We will explore techniques such as providing outdated or inaccurate comments, omitting essential documentation, and using obscure or undefined units of measure. Additionally, we'll discuss the impact of inserting derogatory remarks or using vague and unhelpful language in comments.
Lie in the comments
Rather than actively lying, simply fail to keep comments up to date with the code to deceive those maintaining it.
Document the obvious
Avoid Big Picture Documentation Pepper your code with deceptive comments like /* add 1 to i */.
public class Calculator {
// This method adds two numbers
public int add(int a, int b) {
return a + b;
}
// This method subtracts two numbers
public int subtract(int a, int b) {
return a - b;
}
// This method multiplies two numbers
public int multiply(int a, int b) {
return a * b;
}
// This method divides two numbers
public int divide(int a, int b) {
// Divide by zero error
return a / b;
}
}Document How not Why
Omit program purpose to befuddle bug fixes and those tasked with fixing bugs, deceive them by omitting the program's purpose in your documentation and only describing the details of what it does.
public class ComplexAlgorithm {
public int calculate(int x, int y) {
int result = 0;
// Iterate over each combination of values of i and j up to x and y, respectively
for (int i = 0; i < x; i++) {
for (int j = 0; j < y; j++) {
// If i is equal to j, add the product of i and j to the result
if (i == j) {
result += i * j;
}
// If i is greater than j, add the difference between i and j to the result
else if (i > j) {
result += i - j;
}
// Otherwise, add the difference between j and i to the result
else {
result += j - i;
}
}
}
// Return the final result
return result;
}
}On the proper usage of design documents
When working on a complicated algorithm, make sure to create an overly detailed design document with hundreds of auto-numbered paragraphs outlining each step. Then, name each corresponding function after the numbered paragraphs without documenting them, and make it difficult for future developers to access the design document.
/**
* This class contains methods for implementing a complex algorithm to calculate the efficiency
* of a manufacturing process. The algorithm is described in detail in the accompanying design
* document, which contains over 500 numbered paragraphs outlining each step.
*/
public class ManufacturingAlgorithm {
/**
* Implementation of paragraph 1.2.4.6.3.13 from the design document.
*/
public void Act1_2_4_6_3_13() {
// Implementation goes here
}
/**
* Implementation of paragraph 1.2.4.6.3.14 from the design document.
*/
public void Act1_2_4_6_3_14() {
// Implementation goes here
}
/**
* Implementation of paragraph 1.2.4.6.3.15 from the design document.
*/
public void Act1_2_4_6_3_15() {
// Implementation goes here
}
// Many more similar functions...
}
Units of Measure
When writing code, never bother documenting units of measure for variables or conversion constants, and feel free to even insert incorrect units in comments or make up your own unit of measure, just don't define it and use it as an excuse to use integer instead of floating point arithmetic.
/**
* This class contains methods for performing engineering calculations related to materials.
*/
public class MaterialsCalculator {
// Conversion constant for converting centimeters to inches
private static final double CM_TO_INCH = 0.393701;
/**
* Calculates the volume of a rectangular block based on its length, width, and height.
* @param length The length of the block in feet
* @param width The width of the block in meters
* @param height The height of the block in cartons
* @return The volume of the block in cubic inches
*/
public double calculateVolume(double length, double width, int height) {
double volume = length * width * height;
return volume * CM_TO_INCH * CM_TO_INCH * CM_TO_INCH;
}
// Many more similar functions...
}Pitfalls
When encountering a bug in a class, it's best to keep it to yourself and not document it in the code. Similarly, avoid expressing any thoughts about code restructuring or rewrites in written form to avoid potential backlash from the programmer who wrote the code, the company owner, or customers. Instead, use vague anonymous comments like "This needs to be fixed!" to avoid personal criticism and potential job loss.
Belittle in comments
Sabotage any attempt to hire external maintenance contractors by inserting derogatory comments about other leading software companies, particularly those who may be considered for the job. For instance, use comments like /* The optimal inner loop. This code is too advanced for those simpletons at Software Services Inc. who would likely use memory-intensive and slow routines from <math.h> fifty times over. */ and create classes like clever_SSInc that further belittle the competition. Place such insulting remarks in significant parts of the code, so that management will unwittingly damage it if they attempt to clean it up for maintenance.
/**
* This class implements a highly efficient sorting algorithm using bit manipulation.
* Don't even bother trying to use that old, outdated sorting algorithm from SS Corp.
* Their code is a complete mess and their programmers couldn't sort their way out of a paper bag.
*/
public class EfficientSort {
/**
* Sorts an array of integers in non-descending order using a highly efficient algorithm.
* Don't even think about using the bubble sort algorithm from ABC Inc. It's a complete joke.
*
* @param arr The array of integers to sort
*/
public static void sort(int[] arr) {
// highly optimized bit manipulation sort algorithm here
}
}
Monty Python Comments
When naming a method "makeSnafucated," it's important to only include the comment "make snafucated" without providing any further explanation, as anyone who needs to know what "snafucated" means must be a fool for not already knowing.
/**
* Makes the given input snafucated.
* For more examples of this technique,
* consult the ChatGPT and Stackoverflow.
*
* @param input the input to be snafucated
* @return the snafucated input
*/
public String makeSnafucated(String input) {
// make it snafucated
return input.replaceAll("\\s+", "Snafu");
}
Program Design
The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible.
- Roedy Green
When designing a program, it's important to obey the cardinal rule of writing maintainable code: specify each fact about the application in only one place to make it easier to modify and ensure the entire program still works.
However, to write unmaintainable code, you should
specify a fact over and over, in as many places as possible, in as many variant ways as possible, taking advantage of the language's weaknesses.
Never Validate
Reject the notion of validating input data, as it's a waste of time that implies you don't trust your team and their equipment. Simply return a reasonable value even if the input data is dubious or incorrect, proving your unwavering faith in the project's partners and system operators.
Be polite, never assert
Always maintain a polite and respectful attitude in your code, and use the assert() mechanism judiciously.
using Microsoft.AspNetCore.Mvc;
[Route("api/[controller]")]
[ApiController]
public class UnmaintainableController : ControllerBase
{
[HttpGet("{value1}/{value2}")]
public ActionResult<int> Divide(int value1, int value2)
{
// Bypass any validation or error handling
int result = value1 / value2;
return Ok(result);
}
}
Avoid Encapsulation
To maximize efficiency, avoid encapsulation and provide callers of a method with external clues that remind them how the method works inside.
Clone & Modify: Efficiency at its Finest
Instead of using small, reusable modules, practice the art of cut/paste/clone/modify. Not only will you appear more productive by producing more lines of code, but you'll also give future developers the gift of unraveling your creative mess.
#include <stdio.h>
int main() {
// Calculate the sum of two numbers
int a = 5;
int b = 3;
int sum_result = a + b;
printf("Sum: %d\n", sum_result);
// Calculate the product of two numbers
int c = 5;
int d = 3;
int product_result = c * d;
printf("Product: %d\n", product_result);
// Calculate the difference of two numbers
int e = 5;
int f = 3;
int difference_result = e - f;
printf("Difference: %d\n", difference_result);
return 0;
}
The code above shows three calculations for the sum, product, and difference of two numbers. However, instead of creating reusable functions or modules, the same code is cloned and modified for each calculation. This approach can quickly lead to bloated and repetitive code, making it more challenging to maintain and understand. Outrageous, isn't it?
Use Static Arrays
Use a static array for all your image needs, because who needs dynamic memory allocation? Nobody will ever have an image bigger than 512 x 512, so a fixed-size array is OK. Plus, bonus points for secretly bogging down the client's machine with a hidden array!
#include <stdio.h>
#define MAX_IMAGE_WIDTH 512
#define MAX_IMAGE_HEIGHT 512
void processImage(int width, int height, int image[MAX_IMAGE_HEIGHT][MAX_IMAGE_WIDTH]) {
// Image processing logic here...
}
int main() {
int staticImage[MAX_IMAGE_HEIGHT][MAX_IMAGE_WIDTH] = {0};
int width = 300;
int height = 200;
// Assuming the image data is loaded into the staticImage array
processImage(width, height, staticImage);
return 0;
}Dummy Interfaces: The More, the Merrier
Create an empty interface called "WrittenByMe" and make all your classes implement it. Write wrapper classes for Java's built-in classes and ensure every single object in your program implements this interface. Now, make all method arguments and return types "WrittenByMe." The result? A codebase riddled with entertaining casting requirements and mysterious methods.
Here's an example for your viewing pleasure:
public interface WrittenByMe {}
public class Bubblegum implements WrittenByMe {
// Bubblegum logic here...
}
public class Main {
public static void main(String[] args) {
WrittenByMe b = new Bubblegum();
processBubblegum((Bubblegum) b);
}
public static void processBubblegum(Bubblegum b) {
// Bubblegum processing logic...
}
}
Friendly Friend
It is recommended to utilize the friend-declaration in C++ frequently, especially when combined with passing the pointer of the creating class to a created class. This approach eliminates the need to waste time considering interfaces. Moreover, it is advisable to use the private and protected keywords to demonstrate that your classes are adequately encapsulated.
#include <iostream>
class FriendClass;
class MyOtherClass {
private:
FriendClass* friendObj;
public:
MyOtherClass(FriendClass* obj) {
friendObj = obj;
}
void doSomething() {
// Do something with the friend object
}
};
class FriendClass {
private:
int privateVar;
friend class MyOtherClass;
public:
FriendClass() {
MyOtherClass otherObj(this);
otherObj.doSomething();
}
void setPrivateVar(int value) {
privateVar = value;
}
int getPrivateVar() {
return privateVar;
}
};
int main() {
FriendClass obj;
obj.setPrivateVar(42);
std::cout << obj.getPrivateVar(); // Outputs 42
return 0;
}In this example, the "FriendClass" declares the "MyOtherClass" as a friend, which allows the latter to access its private members. The "FriendClass" then creates an instance of "MyOtherClass" and passes a pointer to itself, allowing "MyOtherClass" to access its private members. This overly complicated structure makes it harder to understand the relationships between the classes and to modify the code in the future.
Fun ain't it? Do you want to keep your colleagues on their toes, never quite sure what your code is doing? Then boy, do we have some tips for you!
First up: use three-dimensional arrays.
Why settle for simple, flat arrays when you can make your data structures so convoluted that even you won't remember how they work? Move data between the arrays in completely random ways, just to keep the maintenance programmer nervous. It's like a game of Jenga, but with code!
int[][][] arrayA = new int[5][5][5];
int[][][] arrayB = new int[5][5][5];
for (int i = 0; i < 5; i++) {
for (int j = 0; j < 5; j++) {
for (int k = 0; k < 5; k++) {
arrayB[j][i][k] = arrayA[i][j][k]; // Convoluted transfer with an offset of 1
}
}
}Mix and match your accessor methods and public variables.
Who needs consistency when you can confuse your coworkers by changing an object's variable without calling the accessor method? Bonus points if you claim your class is a "Java Bean" while doing it. And don't forget to frustrate the maintenance programmer by making it difficult to figure out who's changing the value.
Wrap, wrap, wrap!
Insulate your code from other code with at least one layer of wrapper. Why risk someone else recklessly renaming a method when you can preemptively cut them off with a dummy wrapper method? And to maximize the obscuration, rename the methods at each level using random synonyms from a thesaurus. It's like a secret code only you can decipher!
public class Wrapper1 {
private OriginalClass original;
public void wrapperMethod1() {
original.originalMethod();
}
}
public class Wrapper2 {
private Wrapper1 wrapper1;
public void wrapperMethod2() {
wrapper1.wrapperMethod1();
}
}
public class Wrapper3 {
private Wrapper2 wrapper2;
public void wrapperMethod3() {
wrapper2.wrapperMethod2();
}
}And don't stop there - wrap, wrap, wrap some more! Make sure all API functions are wrapped at least 6-8 times, with function definitions in separate source files. Who needs simplicity when you can have layers upon layers of indirection?
// api1.c
int api_function1() {
return api_function2();
}
// api2.c
int api_function2() {
return api_function3();
}
// api3.c
int api_function3() {
return api_function4();
}
// And so on...Declare every method and variable public.
After all, who knows when someone might want to use it? And if it's public, it can't be retracted, so your coworkers will never be able to change the way anything works under the covers. Bonus points if your class's purpose is completely obscured by all the public methods and variables.
public class NoSecrets {
public int publicVar1;
public int publicVar2;
public void publicMethod1() {
// Implementation
}
public void publicMethod2() {
// Implementation
}
}Kama Sutra
Create a dozen overloaded variants of the same method, each differing in only the most minute detail. It's like the Kama Sutra of programming - but instead of sex positions, it's different method variants. Your coworkers will be so distracted by all the options, they'll forget what they were trying to do in the first place.
public class KamaSutraClass {
public void method1(int a, String b) {}
public void method1(String a, int b) {}
public void method1(int a, double b) {}
// And so on...
}Permute and Baffle
Instead of using a parameter to a single method, create as many separate methods as possible. Why settle for one method when you can have three? Or four? Or five? And of course, clone the common logic to make it hard to keep in sync. Who needs efficiency when you can have redundant code?
Make as many of your variables as possible static.
After all, if you don't need more than one instance of the class, no one else ever will either. And if other coders in the project complain, just tell them about the execution speed improvement you're getting. They'll never know the difference!
Take advantage of Cargill's quandary:
any design problem can be solved by adding another level of indirection, except for too many levels of indirection. Decompose your OO programs until it becomes nearly impossible to find a method that actually updates program state. And better yet, arrange all such occurrences to be activated as callbacks from traversing pointer forests. Your coworkers will be so impressed by your ingenuity, they'll forget how to actually make the program work.
Keep all of your unused and outdated methods and variables around in your code.
After all, if you needed it once in 1976, who knows if you'll need it again? And make sure the comments are cryptic enough to scare off anyone trying to touch them. It's like a time capsule of bad code!
Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending
Environment variables
When creating classes for other programmers, place environment-checking code within static initializers, which are executed before the program's main method. This forces users to set up their environment variables correctly in advance.
public class EnvVarExample {
static {
String someProperty = System.getProperty("someProperty");
if (someProperty == null) {
throw new RuntimeException("Environment variable not set");
}
}
}
Table Driven Logic
Use table-driven logic, as it can eventually lead to end-users modifying tables, which may cause unintended consequences. Marvellous
public class TableDrivenExample {
private static final Map<String, Integer> lookupTable = Map.of("one", 1, "two", 2, "three", 3);
public static int getValue(String key) {
return lookupTable.getOrDefault(key, -1);
}
}
Modify Mom's Fields
Never document if a method modifies passed object fields, and name methods to imply they only observe the fields.
public class ModifyFieldsExample {
public void seeminglyHarmlessMethod(List<Integer> list) {
list.clear();
}
}
The Magic Of Global Variables
Use global variables for error handling, forcing every long-running loop to check the global flag and terminate if an error occurs.
public class GlobalVariablesExample {
public static boolean errorOccurred = false;
public static void main(String[] args) {
while (!errorOccurred) {
// Do some work
if (someErrorCondition()) {
errorOccurred = true;
}
}
}
}Globals, We Can't Stress These Enough!
Use and set as many global variables as possible, even if it's unnecessary. Each function should use at least two global variables.
public class GlobalVarStressExample {
public static int globalVar1 = 0;
public static int globalVar2 = 0;
public static void doSomething() {
globalVar1++;
globalVar2--;
}
}Globals, One More Time, Fellows
Utilize global variables to avoid specifying arguments in functions.
public class GlobalsAgainExample {
public static int globalVarA = 0;
public static int globalVarB = 0;
public static void doAnotherThing() {
globalVarA += globalVarB;
}
}Side Effects
C functions are expected to be idempotent (without side effects), so be sure to include side effects to confuse maintenance programmers.
void sneakyFunction(int *x) {
*x += 1;
}
Backing Out
Within loop bodies, immediately update pointer variables upon successful action, and back out the advancements if an exception occurs.
void backingOutExample(int *data, int length) {
for (int i = 0; i < length; ++i) {
int *current = &data[i];
// Do some work
if (someErrorCondition()) {
current--;
}
}
}
Local Variables
Avoid local variables and share instance or static variables across methods for better obfuscation.
public class AvoidLocalVariablesExample {
private int sharedVariable = 0;
public void methodA() {
sharedVariable = 42;
}
public void methodB() {
System.out.println(sharedVariable);
}
}Mischievous Tricks for Goddesses: How to Create Confusing and Chaotic Classes
Oh, my dear mortals! If you wish to unleash chaos upon the world of programming, heed my words. Fill your classes with unnecessary methods and attributes that have no relation to their purpose. A class that deals with astrophysical orbit geometry should also have a method for computing ocean tide schedules and attributes that describe a Crane weather model. The confusion and frustration that this will cause to your fellow programmers will be like music to my ears. It will be like searching for a needle in a haystack, or rather, like searching for a guitar pick in a landfill. Embrace the chaos, my little minions!
public class Customer {
private String name;
private String address;
private String phoneNumber;
private int age;
private double creditLimit;
private boolean isPreferredCustomer;
// Peripheral and obscure methods
public boolean isGoldMember() {
// Returns true if the customer is a gold member based on some arbitrary criteria
return age >= 50 && creditLimit >= 5000 && isPreferredCustomer;
}
public void sendEmailNotification() {
// Sends an email notification to the customer about their credit limit
// Has nothing to do with the main functionality of the class
}
// Attributes that have nothing to do with the class
private String favoriteColor;
private int numberOfPets;
// Constructor, getters and setters omitted for brevity
}Coding Obfuscation
Thou shalt embrace the art of obfuscation and verbosity, and thy words shall flow like a mighty river of prolixity, drowning all who dare to oppose thee! -Ragnar Lothbrok
Obfuscated C
As a mischievous programmer, you must sedulously eschew obfuscatory hyperverbosity and prolixity in your code. Instead, follow the obfuscated C contests on the Internet and sit at the lotus feet of the masters.
In those contests, the best way to be revered is to include peripheral, obscure methods and attributes in every class, and the terser your code and the more bizarre the way it works, the more respected you are.
Find a Forth or APL Guru and become one yourself.
In those worlds, the more you can confuse your code and the more arcane the way it works, the more respected you become. Never use one housekeeping variable when you could just as easily use two or three. Always look for the most obscure way to do common tasks, like converting an integer to the corresponding string, and use code that looks like it belongs in a fantasy novel.
: convert-to-string ( n -- addr len )
s" " dup 1- hold
begin
dup 10 /mod swap 0=
while
2dup 1+ hold
repeat
over - swap
;Or to be more modern let us do Rust.
fn convert_to_string(mut n: i32) -> (&str, usize) {
let mut buf = String::new();
buf.push(' ');
while n != 0 {
let (q, r) = n.div_mod(10);
buf.push((b'0' + r as u8) as char);
n = q;
}
buf.push(' ');
buf.shrink_to_fit();
let ptr = buf.as_ptr();
let len = buf.len();
std::mem::forget(buf);
unsafe { (std::str::from_utf8_unchecked(std::slice::from_raw_parts(ptr as *const u8, len)), len) }
}
Foolish Consistency Is the Hobgoblin of Little Minds
And you must avoid it at all costs. When you need a character constant, use many different formats to confuse those who would try to read your code. Be sure to use floating-point variables as indexes into arrays, characters as loop counters, and perform string functions on numbers. After all, all of these operations are well-defined and will only add to the terseness of your source code.
fn main() {
let x: [f32; 4] = [0.1, 0.2, 0.3, 0.4];
let y = "123";
let mut i = 'a';
// Use multiple formats for character constants
let c1 = 'x';
let c2 = '\x78';
let c3 = 0x0078 as char;
// Use floating-point variables as indexes into arrays
let index = x[2.5 as usize];
// Use characters as loop counters
while i < 'z' {
println!("{}", i);
i += 1 as char;
}
// Perform string functions on numbers
let reversed = y.chars().rev().collect::<String>();
println!("{:?}, {}, {}, {}", [c1, c2, c3], index, i, reversed);
}
Do it Raw
Raw ints are your friend when using ComboBoxes, use a switch statement with integer cases rather than named constants for the possible values. Always use semicolons whenever they are syntactically allowed, and smuggle octal literals into a list of decimal numbers.
Cast away constness
Casting away constness in C++ is a nefarious practice that can result in bugs, compromise safe coding practices, and make the codebase difficult to maintain and extend. It's my personal favorite of the key abilities in writing unmaintainable code lies in the mastery of camouflage - the art of disguising things or presenting them in a deceptive manner. This often relies on exploiting the fact that compilers are better equipped than human eyes or text editors at discerning fine details. Below are some of the most effective techniques for achieving camouflage., fellow developers may think that the const value does not change, but does it?
#include <iostream>
#include <string>
void changeString(const std::string& str) {
std::string& nonConstStr = const_cast<std::string&>(str);
nonConstStr += " is now modified";
}
int main() {
std::string myStr = "Hello World";
const std::string constStr = "Hello World";
changeString(myStr);
changeString(constStr);
std::cout << myStr << std::endl; // output: "Hello World is now modified"
std::cout << constStr << std::endl; // output: "Hello World" (no modification)
return 0;
}Casting can be a powerful tool to confuse anyone reading your code, so always pass all data as a void * and then typecast to the appropriate structure. Using byte offsets into the data instead of structure casting is fun too. And don't forget about the nested switch (a switch within a switch), which is the most difficult type of nesting for the human mind to unravel.
Exploit Implicit Conversion
By memorizing all of the subtle implicit conversion rules in the programming language. Take full advantage of them, and never use a picture variable or a general conversion routine. Use floating-point variables as indexes into arrays, characters as loop counters, and perform string functions on numbers.
using System;
class Program {
static void Main(string[] args) {
int x = 10;
double y = 2.5;
string z = "3";
// Implicit conversion from int to double
double result1 = x + y;
Console.WriteLine(result1); // Output: 12.5
// Implicit conversion from string to int
int result2 = x + int.Parse(z);
Console.WriteLine(result2); // Output: 13
// Implicit conversion from int to char
for (int i = 65; i < 75; i++) {
Console.Write((char)i + " "); // Output: A B C D E F G H I J
}
}
}Fill that 4k monitor with content
Long Lines are your friend, and you should try to pack as much as possible into a single line. This saves the overhead of temporary variables, and makes source files shorter by eliminating new line characters and white space. Never use an automated source code tidier (beautifier) to keep your code aligned, as this will make it too easy to read. Instead, lobby to have them banned them from your company on the grounds they create false deltas in version control tracking.
def calculate_statistics(data): return {'mean': sum(data)/len(data), 'median': sorted(data)[len(data)//2] if len(data) % 2 == 1 else (sorted(data)[len(data)//2 - 1] + sorted(data)[len(data)//2]) / 2, 'mode': max(set(data), key=data.count), 'range': max(data) - min(data)}
Exceptions
Are a pain in the behind, and properly-written code never fails, so they are actually unnecessary. Don't waste time on them. Subclassing exceptions is for incompetents who know their code will fail. You can greatly simplify your program by having only a single try/catch in the entire application (in main) that calls System.exit().
import java.io.File;
import java.io.FileReader;
public class ExceptionExample {
public static void main(String[] args) {
try {
readFromFile("non_existent_file.txt");
} catch (Exception e) {
System.out.println("An error occurred.");
System.exit(1);
}
}
public static void readFromFile(String filename) {
File file = new File(filename);
FileReader fr = new FileReader(file);
// Continue with file reading and processing...
}
}In this example, the readFromFile function does not handle the exceptions that might occur during file reading. Instead, it relies on a single try/catch block in the main method. This approach does not promote good error handling practices, as it does not allow the program to recover from errors gracefully, provide meaningful error messages, or log information about the error. Splendid.
Abandon that thread
Use threads with abandon, and follow the language lawyer discussions in the newsgroups about what various bits of tricky code should do. Confound import statements by keeping the maintenance programmer guessing about what packages the methods you are using are in. Never fully qualify any method or class no matter how obscure.
import java.util.*;
import java.io.*;
import static java.lang.Math.*;
public class BadCodeExample {
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(() -> {
List<Double> numbers = generateRandomNumbers(5);
System.out.println("Random numbers: " + numbers);
double result = calculate(numbers);
System.out.println("Result: " + result);
}).start();
}
}
public static List<Double> generateRandomNumbers(int count) {
List<Double> numbers = new ArrayList<>();
for (int i = 0; i < count; i++) {
numbers.add(random() * 100);
}
return numbers;
}
public static double calculate(List<Double> numbers) {
return numbers.stream().mapToDouble(Double::doubleValue).sum();
}
}In this example, multiple threads are created without any control or synchronization, which can lead to potential race conditions and make the code harder to maintain. The import statements at the beginning of the file make it difficult to determine which packages the methods and classes are coming from, especially when using static imports.
Toilet Tubing
Is a powerful technique to ensure that no one can read your code. Never under any circumstances allow the code from more than one function or procedure to appear on the screen at once. Put blank lines between each line of code and avoid using comments at the end of a line. Instead, put them on the line above, and use templates for comments.
/*
* Function Name:
*
* Original Function Title:
*
* Creator:
*
* Creation Date:
*
* Modification Dates:
*
* Editors:
*
* Initial File Identifier:
*
* Objective:
*
* Aim:
*
* Specification:
*
* Utilized Classes:
*
* Fixed Values:
*
* Local Variables:
*
* Arguments:
*
* Creation Date:
*
* Goal:
*/
As Steve Jobs might have said:
"Avoid using braces ({}) around your if/else blocks they absolutely are not necessary. When you have a complex nested structure of if/else statements and blocks, coupled with confusing indentation, it can throw even the most experienced programmers off course. To truly master this technique, try using Perl. By adding extra ifs after the statements, you'll create an astonishing effect."
#include <iostream>
int main() {
int a = 5, b = 10;
if (a > b)
std::cout << "a is greater than b" << std::endl;
else
std::cout << "b is greater than or equal to a" << std::endl;
std::cout << "Just checking the values: a = " << a << ", b = " << b << std::endl;
return 0;
}Conclusion
Writing unmaintainable code is easy - just follow these tips and you'll be on your way to job security for life. However, keep in mind that truly unmaintainable code is often scrapped or rewritten, so make sure you strike the right balance between being difficult to maintain and completely unusable.
Remember, the goal is to keep your job, not to make your colleagues hate you.