No tests. At all. Ever.

Writing an entire app in a single file that ends up being a few thousand lines of code. It started as a few hundred, but grew from there (like always), and now there's no turning back until it's launched and validated! No use wasting time refactoring until I know it'll work.

Oh dear. I've done just about everything on this page...

I never hide data. All structs with all public members. Even if I write an API around that, I can still just access everything directly if I want to.

When I use raw pointers, I usually don't check for nullptr.

I abuse unions and their initial members and don't bother checking tags even if I tag them.

Does it compile? Good. Does it run? Good. If I leave it running does it eat all my RAM? No? it's probably fine then.

I tend not to push changes for weeks or sometimes months, and my commit message is basically that I forgot everything I actually changed. Also, my commit messages are terrible.

I keep one big text file full of notes, comments and old code pasted in. My source code itself tends not to be commented well as a result.

Premature optimization.

Cause it's fun.

I have a severe case of this. So few personal projects even get started because I get caught up in scalability and what not.

Like 3 nested listcomps on one line (Python).

Proper async code tends to go out the window where timers will suffice. It's filthy, but often faster and it works for whatever narrow problem the one-off script in question is solving.

Hard code passwords and temporary filenames.

Perl one-liners in bash scripts. The kind that don't use spaces or bracket. Of course one-character variable names and use of special variables like $\, $| or $& (http://perldoc.perl.org/perlvar.html). Execute code withing regular expressions. Almost obfuscation. I assume they break whenever a new minor version of Perl is released.

Ditch optparse or argparse -- "flag = '--flag' in sys.argv" or "if len(sys.argv) > 1: arg = sys.argv[1]" will usually do...

Nice. Haha I use a switch statement:

    process.argv.forEach((arg, i, argv) => {
      switch (arg) {
        case "--foo":
          foo = argv[i + 1]
          break
        case "--bar":
          bar = argv[i + 1]
          break
      }
    })

Writing extensive TODO comments for future features instead of actually implementing them. Never read a single ToDo comment afterwards. Ever.

I'll write tests when the product makes money.

At least write test on payment stuff, I learned the hard way by screwing up payment system when user emailed me why he can't go through payment.

It really amazes me how many companies (especially the ones with an avaricious reputation such as health insurance companies) don't take the payment system seriously.

Minimal comments and documentation. Why should I comment or document if no one else will ever see it maintain it?

I'm guilty of the exact opposite - sometimes I comment too much, to the point that the code becomes LESS readable...

or a huge block of comments at the head of my main file, with all the TODOs...

Also, not using version control, and only switching to it when the project is already a considerable size...

Profanity. It can look like a key party got out of hand in there. Use g for a string variable at least once.

I can never resist naming Assembly variables ass. Also leads to lots of fun variations: dynamicAss, assBuilder, assTypes, ...

I got bitched out by a boss once for using the number 666 in a unit test.

What's the significance of using 'g' as a variable name?

Not just variable name a "string" variable name,

See g string ^^

Skipping tests...

Story of my life, unless someone is paying for it.

Debugging by writing variables and intermediate steps to the console.

The ever-present possibilty of open-sourcing on github and getting code-reviewed by future employers hangs over my head like the sword of Damocles.

That's one of the reasons I no longer use Github. I don't want every line of code I write to be used as part of a hiring filter, much less just the languages I'm tagged with or the number of stars in my repos or in anything I contribute to.

The more useless social media BS Github piles onto its site the more it becomes the new Linkedin... no thanks.

That sounds a bit like fretting over the fine details of which clothes to wear. There's a good chance the other party is not that interested, and does not dwell on or even notice these things.

Global variables... I'm ashamed.

Single letter variable names.

and reuse of them!

oh, I too like to live dangerously!

Skipping the getter/setter dance for POJOs and just using public fields.

You at least made them final right ?

All throw away db table names starts with suxx_.

I do all of these things in the same block of code.

Somebody off me.

int x;

String str;