When you're coding are there certain things that you fret and worry about, specific topics that preoccupy your mind as you type (both new code and when maintaining/bugfixing existing code)?

These need not be bad things, more like voices in our heads that help us with the quality of our code, and prevent us from just hacking things out.

The list that I have is something like this:

  • Should I be refactoring this?
  • Is this code generic enough / too generic?
  • Is this variable/function/class name sensible?
  • This code seems a bit complex, am I missing something obvious here?
  • Have I condidered the edge cases?
+2  A: 

How about: "Am I going to make de deadline?"

Sure you can, but it won't work properly. :-)
+8  A: 

Did I leave the oven on?

Sam Meldrum
+26  A: 
  • Am I going to understand this in 3 months time?
  • Am I trying to be too clever: is there a simpler way to get the job done?
  • Can I write this in such a way as to make some parts re-usable?
  • Have I written anything before that I could re-use here?
  • What's for dinner?

EDIT: after recent painful experiences

  • Am I going to be able to easily test this?
Alabaster Codify
+6  A: 

Does this pass my unit-test?

"The History of every major software project tends to pass through three distinct and recognisable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases. For instance, the first phase is characterised by the question How do I solve this? the second by the question Why is this failing? and the third by the question Where are the unit-tests?"

with apologies to Douglas Adams

+4  A: 


Carl Seleborg
+8  A: 
  • Is there a way to break this horribly.
+17  A: 

Is the first programmer who will read the code going to send a snippet to The Daily WTF?

+4  A: 

There are many questions that I keep asking myself as I code.

Is this the best way to do this?
Has someone already done this?
Is this absolutely necessary?
Will this be easily understood?

There are many more I am sure but these are the most prominent.

Andrew Hare
+1  A: 

Worrying what I do now cannot cope when there's a revision on user's specifications. Some programmers, in order to beat deadlines, just churn out code with utter disregard if their code will be future-proof.

"Don't code today what you can't debug tomorrow"

Michael Buen
+1  A: 
  1. Could this be done more elegantly / simpler?
  2. Is this a bulletproof design or is there some huge flaw?
  3. Is the customer going to understand how to use this thing?
  4. When is lunch?
+4  A: 

Does this feel right?

Will this be embarrasing when someone else sees it?

+4  A: 

Edge conditions.

What is the most unlikely thing that someone could put in here to deliberately break my bit of code, and how can I stop them.

+2  A: 

What is my rep doing on stackoverflow.

+2  A: 
  • should I really touch this (undocumented, sloppily written) code?
  • will I ever be able to rewrite this mess from scratch?
  • why me?
  1. Refractoring to Minimalism: i dislike code a lot of method and variables;
  2. Logging : I not log a lot but in ALL the try/catch block i log the message and stacktrace with level ERROR (i'm referring to Java style)
  3. Requires of user

When changing large existing code bases;

  • What else am I going to break by making this change?
  • Is the automated regression suite being used strong enough to catch these breakages?

If I don't have a regression suite, and have to refactor, that is when I get really twitchy.

Shane MacLaughlin
+2  A: 

Has the bicycle already been invented here maybe?

+2  A: 

I'm worrying about the assumptions I make, e.g. can I assume this file will always be there ?.

I think that the answer there is definitely "no"...
Richard Ev
It's a good answer, assumptions are easy to skip. His "can I assume" example was an example, not a direct question.
+2  A: 

How am I going to test this to make sure it does what I think it does?

Bill the Lizard
My order would be how can I write the test so that when I write the code, it does what I think it does. This would be preceded by do I really know what this is supposed to do or should I be talking with someone about it.
That's useful if you adhere strictly to TDD, which I don't always do.
Bill the Lizard
Then practise TDD!
  1. Does it work?
  2. How can I verify that?
  3. Can I maintain it?
Brian Rasmussen

Many great ideas. Additional thoughts:

+1  A: 

As I'm writing new code, I'm usually thinking:

  • Will anything else need to do this?
  • How can I build this such that I never have to build it again?
  • If my incredibly bright programmer colleagues see this, will I be proud of it?
  • Am I following the code style standards defined by the community?

And I worry about:

  • If this is incredibly and violently successful, will it be able to scale to millions of users?
  • If someone with malicious intent starts playing with it, have I missed something that would allow them to do serious harm?
  • As I'm totally zoning out into my screen here, is there anything else I'm forgetting to do? Like eat?
Sean Edwards
+2  A: 

If I change this, what will break? (Had to think like this when inheriting a codebase).


How do/will I test this?


As a recent graduate, I find that I am bombarded with many different opinions on how good code ought to be designed, implemented, and tested, so I am constantly re-factoring my way of thinking as I try to mimic practices that I agree with and try to avoid those that I don't agree with.

As a result, while I'm coding, I raise questions in my head, such as:

  • If I had to explain my design to one of my mentors, would I be proud of what I've done?
  • Are my classes generic enough for someone besides me to re-use them?
  • Is this code too generic to be applied to anything useful?
  • Would my peers think that I "over-designed" this project?
  • What would a concrete version of my abstract class look like?
  • If I had to start over again, what would I do differently?
  • Is there a design pattern that would give me some guidance on this?
  • And of course, do I have time to read a few articles on StackOverflow before lunch?

Economic World Crisis

  • Who will understand this if I get fired?

Sushi, Steak or Pasta for Lunch?

Michael Stum
mmm Sushi... but in this economy... PB )
  • To comment or not to comment.
  • "Please lord, let JBoss handle this many threads"
  • Why me
  • OOP can be evil in the wrong hands
  • I should've studied medicine

I usually wonder if my code will stand up to the scrutiny of my peers. In other words, will it make me look dumb?

Kevin Babcock

Something i didn't already see in the list here:

  • What will my IDE show for intellisence for my classes? Pretty important when making a utility library. You don't just want to expose every property and method.
  • Is the tutorial I borrowed this order of operations from using a deprecated subset of the API?
  • Have I just shot the implementation of a version 2 feature in the foot badly enough that I'll have to redo everything later?
  • Is the database layout about to change?
  • Steak or sushi?
Kim Reece