Scribd
Upload
12 views18 pages

How to write bad code

Uploaded by

Bitno Bitno
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views18 pages

How to write bad code

Uploaded by

Bitno Bitno
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

How to write bad code

using C# and JavaScript

Wekoslav Stefanovski
@swekster
The worst thing about Software
• It can be horribly written
• It can be an unmaintainable mess
• It can be completely instable and untestable
• It can be absurdly undocumented
• But it can still work very well

• There is no connection between the way the code of a


product is made and the end product
• Yet, the code IS the product
Why is Software special?
• It’s relatively new, and very unstable field to work in
• It bootstraps itself
• Not only the standards, but even the definitions are
changing all the time
• It’s changeable at every step of the process
• It’s changing at every step of the process
• Lots of folks are getting left behind
Why we have so much bad code?
1. It works – why change it?
2. I don’t know how to make this
3. I know how to make this
4. I don’t have time right now
5. I don’t know what the current code does
But since there’s so much of it out
there, it must be in demand?

So, what can we do to make some


really bad code?
Anti-patterns
• Something that looks like a good idea
• But it’s not – backfires when used 
• “common response to a recurring problem that is
ineffective and highly counterproductive”

• Analysis Paralysis / Design by committee


• Cargo-cult programming
• Vendor lock-in
• Mushroom management
• Lava flow development
Pattern fetish
• I have this pattern, where could I use it?
• Heavily dependent on the last blog post the architect
had read
• Patterns are good, working and proven practices
• More patterns you use, the gooder the code gets
Shiny new framework
• Code that someone has already written for you
• Highest quality possible
• Solution to most of the problems
• Only issue – change your other problems to fit the
framework
Apocalypse ready
• As a developer, you need to be ready for everything
• Ensure that your code will never ever fail, under any
circumstances
• Efficiently mitigates Murphy’s law
The God Object
• One omnipotent, omnisapient class
• One stop shop for all your needs
• Enables easy location
of methods and code
• Removes all circular
dependency issues
Object Orgy
• Restricted access to state means you only need to rely
on what the developer thought you needed.
• As a user you don’t need contracts, you need function.
• Interactions cannot be predicted in advance
Data Buffet
• Eagerly loading all the data you might need
• Actively anticipates the user actions
• Enables forward-thinking
• Easy access once the loading is done
• Ensures data availability and consistency
Not Invented Here
• Most libraries are intended for general use
• Some libraries have weird licences (something called
open source???)
• Your project has some specifics
that are not covered
• Let’s face it –
you could probably do better
Inner Platform Effect - Softcoding
• When you really, truly need everything to be as dynamic
as possible
• Why not give the power to
decide what is what to the user
• Everything is configurable,
but it can have a somewhat
steep learning curve
Spaghetti code
• Structure takes back seat to functionality
• Everything can go everywhere (e.g. SQL generated in
Javascript)
• Copy / pasta virtuosos
• Also known as Big Ball of Mud
• Alternative to:
• Ravioli code
• Lasagna code
Any Question?

Hopefully you know I’m only joking, right? Right?

You might also like