Efficiency question

Efficient = gets the job done before everyone gets bored and uses another, faster program than yours. This usually means using the right algorithm (since that is generally the deciding factor for efficiency) but if the algorithm is trivial or already perfect then it boils down to writing fast code, which means code which makes good use of memory, utilizes cache coherency to avoid memory latency hits, which uses the CPU as best it can (e.g. if the CPU has instructions to do some stuff faster, you use them), is multithreaded if applicable, and possibly using the GPU to get stuff done faster. Don't worry about trivial optimizations like i++ vs ++i, those weren't even relevant 20 years ago and the compiler does it better than you. Today it's all about parallelism, workgroup division, and cache coherency (though some bottleneck code can still benefit from more aggressive optimization, but as always, benchmark!!)

Cleaner = code that's easy to maintain and refactor, is actually readable, does not blow up when you change a single line of code, uses consistent style and notation, has proper documentation, follows accepted idioms, respects encapsulation, has short but descriptive function/methods, does proper error-checking, does not leak memory, makes good use of language features, is properly organized and divided into code libraries w.r.t. functionality, and tries to make code reusable in other projects (when applicable).

Java has some interesting coding conventions: http://geosoft.no/development/javastyle.html

Even if you don't use them, they can still make you think about your own style and how you can improve it.

What are the industry standards of "clean code"?

I'm pretty sure that one of the big problems in this world is that there isn't a standard on "clean code" :D

1) Which factors determine a program to be efficient or not?
2) And how can my own code be more efficient or at least cleaner?
3) What are the industry standards of "clean code"?

1) This depends entirely on your app. Efficiency is a function of what your program is actually doing. For most code, efficiency is not a concern. As this is For Beginners, the answer is to do anything that works. Only after you have something that works should you measure for slow performance, then use the measurements to make change, measuring again afterword to ensure the change actually improved the situation. Multi-GHz machines are really fast.

2) "Clean code" has no real definition. Generally it means maintainable, as Bacterius pointed out above.

To me, clean code means that the code requires no explanation. I can give the code to my co-worker, explain nothing about the code and what it does, and ask them to add a feature. They can look over the code briefly and immediately see where the changes belong. Or I can give the code to my co-worker, explain a bug, and ask them to fix it; they can look over it immediately and understand where the bug is likely to hide.

I have seen a lot of code that I can glance over and instantly understand. I have seen a lot of code that makes me scratch my head in frustration.

To improve your skills at writing 'clean code', you need to read a lot of code and actually study what makes it good and what makes it bad. Read books about design patterns and code smells. Do the good things, avoid the bad things.

To further improve your skills as writing high quality code, let people review your work constantly. If you know that somebody is going to complain about it, you are less likely to commit those violations.

3) There are no good industry standards on quality of code. Companies set their own coding standards and best practices and then enforce them with regular code reviews. No code reviews means they don't have any standard, and that is sadly too common.

As an industry and as a field, there is no standard. Individual companies and studios may have their own standards, and individual team may follow them differently.

I love working on teams where everything gets reviewed. My studio adopted ReviewBoard a few years ago, and I love it. Our policy is that everything needs a minimum number of programmers to sign off on every submission. When people are idle during builds or bored at work they can go through ReviewBoard and look for issues in the code, so most changes get approved with team consensus within a few hours or marked up with issues within minutes. Before that we had a buddy-check system where every change required you to find somebody to review your code, along with random checks by leads. It was less good because you were often pulling people of their flow of thought, and there were those people who would just give a cursory glance or approve everything.

What are the industry standards of "clean code"?

I used to work in the production group for a round-the-world trading operation, and a colleague used to say that code was clean enough when you are woken up in the middle of the night because of a problem, you can find the problem quickly, fix it, and not remember anything the next morning. :)

Which factors determine a program to be efficient or not?

how often a given piece of code needs to run in a given amount of time, and how relevant it is to the overall execution time (relative to what is required for a good user experience).

basically, if something doesn't run often or take much time for itself, then there isn't much point of optimizing it.


otherwise, there are the traditional answers:
algorithmic complexity;
avoiding unnecessary layering (this is where basically, one inefficiently-implemented mechanism is layered on top of another inefficiently-implemented mechanism layered on top of ..., to such a degree that a 'trivial' operation will often take considerable amounts of time to execute...);
avoiding doing things more often than necessary;
avoiding using a complex and expensive piece of technology for something which could be handled just as easily with a simpler and lighter-weight piece of technology;
...

And how can my own code be more efficient or at least cleaner?

more efficient:
typically, use a profiler when stuff gets laggy, and look into whatever is near the top of the CPU-time list in the profiler.

this can be either by optimizing the thing itself, or sometimes trying to change things such that it needs to be done less often.


generally, it is a good idea not to worry too much about micro-optimizing unless there aren't really many other good options, and usually micro-optimization will result in only modest gains.

however, there are sometimes cases where this is useful.

What are the industry standards of "clean code"?

Thanks in advance.

often relatively few people can agree as to what exactly is clean code.
much of the time, it ends up boiling down largely into a debate about naming and formatting conventions.

personally, I more like breaking things apart into "black boxes", where most of the "guts" are fairly well isolated, and where things are "generally fairly well behaved" over a "reasonable" range of inputs.

You're asked about efficiency and cleanliness. These are two very distinct things.

For efficiency, you're asking about it from a too broad standpoint. It doesn't really make that much sense to talk about a program's overall efficiency. Programs do all sorts of tasks in response to various stimulants. Some of those tasks may get the job done as efficiently as possible, whilst others may burn thousands, millions, billions, or trillions more CPU cycles than are actually required to solve the task at hand.

The most important thing in regards to efficiency is Big-Oh notation. Often you want to be using the algorithms with the best, or close to the best Big-Oh notation. E.g. You avoid this sort of thing: http://en.wikipedia.org/wiki/Schlemiel_the_Painter's_algorithm.

Sometimes though, the most efficient thing is the simplest thing, particularly when the numbers concerned are very low.

"Clean" is a very broad term, but it generally means well-designed, well written code, that is as simple as possible but not simpler, and adheres to good practices.

"Clean" is not always equal to "efficient", but the best programmers can pull the two quite close together.

The industry standard is, sadly "it sells", and more importantly "it sells early". Efficiency is secondary. Software must be ready to sell before someone else has the same idea, and it must preferrably run on your neighbour's mother's phone.

Nowadays, it is perfectly allowable (and you're not even sneered at) to write software by wrapping a little Javascript around some standard components when you would have used C++ to write a "proper program" a decade ago. If that means you get your software into the appstore within a week (as compared to 6-8 months), nobody cares.

C# is not so immensely successful because it is a "better language" or because the programs run "better" in any way. It is successful because the huge standard library allows average or sub-par programmers to perform more or less equivalently to top-tier programmers (who are much more expensive), and it allows them to do something that "looks the same" in half the time, too. Nobody cares whether it maybe uses 10% more CPU, if it does that. Nobody cares whether it takes up a little more space on the harddisk.

The times when your operating system would fit on a floppy disk are over. The 64GB drive on my Windows 8 tablet was 50% full as supplied by the vendor, with nothing installed but Windows. Repeat that sentence three times in a row, and you'll see that nobody really gives a crap whether the app that you write takes 2MB, 10MB or 20MB.

It doesn't matter whether it takes 3-4 seconds to start up either, all other apps do the same. Even on my rather powerful desktop, larger .NET programs will take up to 30-40 seconds to start up (when they're not cached). That's just how it is, nobody is bothered.

In my opinion, clean design is much to do with minimising the connections between modules. Every program has to be decomposed into multiple modules (sub-problems), and the higher the independence between each of these, the cleaner the program design.

Of course, how you choose to divide a program up can be linked to the algorithms you choose to use. Going back and making a different choice can require a (very) different program architecture, or you end up with a horrible mess :)

Scalability is a much more pressing concern these days than efficiency.

Proverbs concerning efficiency:

• If it ain't broke, don't fix it.
• If it is broke, find the part causing the problem instead of screwing with the whole of the code.
• Almost always, changes to the structure of the program will save you far more time than changes to the bytecode of a function.
• The fastest and most bug-free code is the code that doesn't exist.

Clean code is much more important. Write simple parts with easily understood functionality, then use those simple parts to build other simple parts that are easily understood, ans so forth. The idea is that someone that doesn't know your project can walk up and look at your code and understand what's going on. Observing SRP religiously is a good way of helping this along. You also want to use easily understandable names for everything. No 'foo' and 'bar' in production code. If the variable counts how many derps you have then name it derpCount or something similar. It's not an issue of what naming conventions you use as much as it is a matter of taking the five seconds to think up a descriptive name for things. Avoid needless complexity. Make like things look alike. The best proverb here is from Harold Abelson: "Programs must be written for people to read, and only incidentally for machines to execute."

Asking for 'industry standards' for cleanliness or efficiency is not the correct way to look at things. That's like an Olympic racer asking what the acceptable running speed is. Just do the best you can and always work toward getting better.