You write a program to solve a problem. That problem is accompanied by a specific set of requirements for solving it. If those requirements are met, the problem is solved and the objective is achieved.

That’s it.

Now, the reason that best practices are observed is because some requirements have to do with maintainability, testability, performance guarantees and so forth. Consequently, you have those pesky folks like me who require things like proper coding style. It doesn’t take that much more effort to cross your T’s and dot your I’s, and it is a gesture of respect to those who have to read your code later and figure out what it does.

For large systems, this kind of restraint and discipline is essential, because you have to play nice with others to get it all to work, and you have to minimize technical debt so that the project doesn’t collapse under its own weight.

At the opposite end of the spectrum are those one-off utilities that you write to solve a specific problem right now, utilities that you’ll never use again. In those cases, style and best practices are completely irrelevant; you hack the thing together, run it, and get on with the next thing.

So, as with so many things in software development, it depends.

There’s a wise old quote: “Do not follow in the footsteps of the wise men of old. Seek what they sought.” There are reasons for all of the rules of ‘proper’ coding. Knowing why those rules exist is more important than knowing what those rules are.

There is a rule that you shouldn’t put a test that could be repeatedly recalculated in a for loop like that. In the cases that the rule was invented to remedy (where performance would really be different), it makes sense. In that case, there is only one right answer. In your example, it is known that there is no performance difference and that there can’t be more than a couple dozen iterations. In this case, there are two right answers, either to apply the rule anyway, since it’s simple and won’t hurt anything and could help form good habits, or to ignore the rule, since there is no performance difference to worry about.

I prefer the first right answer, and you appear to prefer the second. You are not wrong about that. I think you are wrong in your idea of what ‘proper’ programming is about. It isn’t about following a randomly selected set of rules that don’t help you and have no purpose. Your not fixing the for loop in the example is actually following a very good rule against premature optimization.

Real proper programming is about following good rules that make sense in an intelligent way.

The proper way to look at this is diminishing returns: comparing the added benefit of developing the program to the cost of the additional development.

Diminishing returns sets in when the marginal benefit is less than the marginal time/effort.

Can you make a business case for moving items.length out of the for loop? Economically, can that change even justify the time spent trying to justifying it? Since there is no difference in the user experience, you will never get anything for even the time spent measuring (other than a useful lesson to remember). The users will not like the program any more than they do, and more copies will not be sold, as a result of that change.

This is not always easy to evaluate, because business cases are filled with unknowns and risks, and are thus susceptible to fall prey to unconsidered factors that will only become obvious in hindsight. Proposed changes can be completely nontrivial, such that they do make a big difference.

Diminishing-returns type of thinking can amount to a hunt for excuses not to take some action, and avoid taking risks, which could in hindsight prove to be a string of missed opportunities.

But sometimes it is obvious when not to do something. If some piece of development seems to require an economic miracle to occur just to pay for the cost of development (break even), it’s probably a bad idea.

When you should not care about your code being “proper”

• If you manage to answer the business goal, and keep it over time with low overhead. (users don’t view source before they pay you)
• MVP / POC – If writing proper code means wasting time on a concept before you know how to make money from it (if you spend years and 45 million dollars writing your app and end up closing shop because it had no market, no one cares how proper was the code)
• When having a life threatening situation (e.g. iron man prototype 1 was a dirty hack, but it got him out of the cave right?)
• or if you simply don’t know how to write proper code (if somene manages to make a living writing non proper code, in today’s unemployment, I say, better write bad code than be homeless)
• if you simply know what your’e doing or think you can get away with it pretending you do

When to write proper code

• If it will have a significant business impact, e.g. performance will impact the revenue, or prevent sales
• If it’s so not proper that maintaining the code becomes a business issue (high maintenance costs)
• If you are a known programmer working on a big open source project
• Same for a big company contributing an in-house library to the world
• If you want to show your work as a portfolio in future interviews

Is performance your main concern? Is that what you’re trying to maximize?

If so, there is a fundamental lesson to learn, and if you do, you’ll be one of the few.

Don’t try to “think” what you should do to make it faster – that’s guessing.
If you’re asking “Should I use this container class or that one?”, or “Should I put length in the loop condition?”, you’re like a doctor who sees a patient and tries to decide what treatment to give without actually questioning or examining the patient.

That’s guessing. Everybody does it, but it doesn’t work.

Instead, let the program itself tell you what its problem is.
Here’s a detailed example.

Do you see the difference?

Your question is “so long as it gets the job done, I don’t care?”

My answer is, “you never know what will happen to your code.” I’ve been involved in so many projects that started out as “hey let me write this quick thing to take care of a user’s problem.” Write it, put it out there, never think about it again.

One time, that thing I wrote morphed into “oh, now the user’s entire department wants to use that code,” which before I could turn around became “the entire company is using that code and now I have to prove it will survive an audit and there’s a 20-person code review scheduled for tomorrow and some vice president has already sold it to our customers.”

I realize you’re “just writing an android game in your spare time” but you never know if that game will take off and become your ticket to fame and fortune. Worse yet, that game could become your ticket to infamy because it keeps crashing people’s phones. Do you want to be the person who gets a job offer because someone’s kids can’t stop playing your game on their phones, or do you want to be the person who gets vilified on message boards like this one?

The answer is that it never matters, and it always matters….

It never matters because programming, proper or not, is a way of achieving a goal, not a goal in itself. If that goal is achieved without “proper” programming that’s fine (from a business perspective it’s often best if the goal can be achieved with no programming).

It always matters because proper programming is a tool that will aid you in achieving your goals. The proper way of doing things is simply a recognition that doing it another way causes more pain in the long run than it saves.

Which answers the question of when you can ignore it — when you’re sure that another way will be easier in the long run (possibly because there will be no long run).

One off tools are typically done as quick and dirty as you can, with little to no error checking or other validation, no logging of exceptions, cut-n-paste code with minor changes or even no changes instead of generic functions, and so forth.

Just watch out: sometimes those quick and dirty apps take on alife of their own, which means all of the short cuts bite you in the…

Or even something trivial like this:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

I know it evaluates item.length on every iteration. However, I also
know items will never be more than 15 to 20 items. So should I care if
I evaluate items.length on every iteration?

Actually in the final code, items.length will not be evaluated in every iteration because the compiler optimizes it. And even if it weren’t, length is a public field in the array object; accessing it doesn’t cost.

So I guess my question to you is this: Is there a threshold when it no longer >matters to be proper? Is it ok to say – “so long as it gets the job done, I >don’t care?”

It really depends on what you expect from your end product; the difference between an average product and a great product relies in details. A car like Tata Nano and a car like Mercedes S “gets the job done” – it takes you from one place to another. The difference relies in details: engine power, comfort, safety and others. It is the same with any product that exists, including software products; for example why would anyone pay to Oracle, IBM or Microsoft for Oracle database, DB2 or MS SQL Server since MySQL and Postgre are free?

If you want to pay attention to the details and obtain a high quality product you should care about this stuff (and about other stuff, obviously).

If you are programming at home for yourself then maybe you can cut a few corners; and when you are experimenting and trying things out this is completely justified.

However take care. In the example you give there’s not really any need to cut that corner, and you need to be careful. This could start a trend and bad habits that you do at home could creep into your code at work. Far better to practice and improve on good habits at home and let them seep into your code at work. It’ll help you and it’ll help others.

Any programming you do and any thinking you do about programming is exercise. Make it worthwhile, otherwise it’ll come back and bite you.

Look on the good side though. You’ve asked about this so maybe you’re already aware of the point I’m making.

If a furniture maker was making a piece of furniture to be used where the quality wasn’t of utmost importance or where the quality might go unnoticed, should they still try to make their cuts straight, and do a proper job joining the pieces together?

Many people see software as craftsmanship. What we build shouldn’t only perform a function, it needs to be reliable, maintainable, robust. Making such software requires skill, and that skill comes from practice.

So, even though the choice of a looping construct for what you are working on today may not matter, the fact that you strive to use the proper constructs at all times will, over time, make you a better programmer.