|
I do a lot of defensive coding in the UI layer.
Natza Mitzi
|
|
|
|
|
Why UI layer and not business layer?
Try not to become a man of success but rather to become a man of value. - Albert Einstein
Ernest Laurentin
|
|
|
|
|
You are right, I also do it in the business layer.
When I wrote the first post my instinct was the UI layer since it has to withstand the unpredictable (user).
When releasing applications that go through a quick QA process I am usually concerned with the UI layer (testing all the "common" states of the application is impossible)
Natza Mitzi
|
|
|
|
|
I do defensive coding everywhere. I never assume any pointer a not NULL. I also check buffer sizes if possible to avoid the chance of overflow. It used to be that this would slow down your application however now when processors execute a simple integer instruction (assuming the pipeline does not stall) in 1 clock tick and there are > 2 billion clock ticks per second...
John
|
|
|
|
|
Programming Rule Number 1.
Assume the person maintaining your code is a homicidal maniac.
And they know where you live.
|
|
|
|
|
Programming Rule Number 2.
Don't assume you'll have left and found a better job by the time they discover the mess you've made 
Your maintainability problems always come back to haunt you.
|
|
|
|
|
Seems self-explanatory. But behind that is a lot of thinking, because ultimately, it's my time wasted if I have a poor architecture, haven't done enough unit testing, commenting, documentation, requirements gathering, etc.
Marc
|
|
|
|
|
Self-explanatory
|
|
|
|
|
I agree with [time] in general because maintainability is very important for me as well.
How fast you can pick up some code and get it done.
Try not to become a man of success but rather to become a man of value. - Albert Einstein
Ernest Laurentin
|
|
|
|
|
On the focus of the application.
|
|
|
|
|
In interesting result has come out of this poll, and being the fastidious programmer I am, I have to say something about it. Most of the comments in response to this poll note maintainability as an "optimization". You could look at good maintainability as "optimizing for the reader", but there is already a term for that: Maintainability!
Optimization is tuning an application to meet a required performance bar. There are usually many ways to achieve that performance bar, and many factors involved (cpu load, memory load, bandwidth, efficiency of algorithms, proper design and architecture, etc. etc.) Sometimes optimizations can be done while improving maintainability. More often than not (im my experience at least), optimizing an algorithm can result in the order of statements becomming "less obvious", which makes the code less understandable (thereby affecting maintainability).
Refactoring is tuning an application to meet the needs of developers and improve maintainability. This is usually the purpose and result of reorganizing and restructuring code (See Refactoring), taking complex methods and classes, breaking them down into smaller, more cohesive, more meaningful subcomponents of the whole.
I think its important that this distinction is understood:
* Optimization tunes an application for performance.
* Refactoring tunes an application for developers and maintainability.
Ok, rant over. :P
|
|
|
|
|
Jon Rista wrote: Optimization is tuning an application to meet a required performance bar.
Exactly! 'Maintainability' in software can essentially be broken down in these subparts:
- Conformance to coding guidelines
- Avoidance (like hell!) of code duplication
- minimization of code complexity
- short code documents - e.g. a single method must not exceed 20 lines
You can measure the above points (using tools like MS StyleCop, Simian, NDepend and the like) and define thresholds for each of it. If you're above some defined threshold, you can optimize your codebase for exactly that.
I'm earning my money with this kind of work, so I can say this for sure.
There's absolutely no reason to rant here...
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: If you're above some defined threshold, you can optimize your codebase for exactly that.
"If you're above some defined threshold, you can refactor your codebase for exactly that." 
|
|
|
|
|
Of course it is refactoring what you actually do to get the desired results. But refactoring is another word for rewriting some piece of code. That's what you usually do if you want to make some change...
So what? 
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
I think you are missing the point. If you look back at your reply you are proving his point about the misuse of the word, optimization.
Thomas Weller wrote: You can measure the above points (using tools like MS StyleCop, Simian, NDepend and the like) and define thresholds for each of it. If you're above some defined threshold, you can optimize your codebase for exactly that.
Optimization refers to rewriting code to improve the application's performance. Refactoring refers to rewriting code to improve maintainability/readability.
|
|
|
|
|
Perhapse a dictionary definition will help clarify what my rant was about (which was the missuse of the word 'optimization' in the context of maintainability, rather than performance).
From dictionary.reference.com:
op⋅ti⋅mize [op-tuh-mahyz] verb, -mized, -miz⋅ing.
–verb (used with object)
3. Computers. to write or rewrite (the instructions in a program) so as to maximize efficiency and speed in retrieval, storage, or execution.
I'm generally prescrpitive when it comes to grammar (i.e. 'winningest' is not a word, the proper form is 'most winning'). I think missuse of words, either through incorrect application of prefixes and suffixes or invalid context, constrews the accuracy and clarity that our language can provide when its used properly. This usually leads to considerable confusion and bad communication in development workshops, causing delays, wasting time, effort, and money, etc. etc. My rant was mostly in jest, and wasn't in any way meant to piss anyone off. I just thought it was interesting how people associated optimization with maintainability ("optimizing for maintainability and readability", "optimize the mantainability of an application", etc.), when in practice the two are distinct goals, often at odds with each other.
|
|
|
|
|
Jon Rista wrote: My rant was mostly in jest, and wasn't in any way meant to piss anyone off.
Don't worry, I don't feel pissed off...
It seems that we have different understandings of the word 'optimization'. (First of all: I'm not a native speaker and I didn't consult a dictionary before writing this.) My understanding of the word optimization is: making your code optimal - not only in regard to runtime behaviour, but to every possible/desired aspect.
I'm not sure if I agree to all of the implications of the above dictionary definition, it seems a bit outdated to me. But basically, we are talking about words and definitions here, and I agree with you that language should be used properly.
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: My understanding of the word optimization is: making your code optimal - not only in regard to runtime behaviour, but to every possible/desired aspect.
That is also my understanding of "optimizing" and, in my view, a far more important one than the restricted optimal computational resource usage.
Since I have started programming, computer performance and resources have increased almost exponentially. My programming abilities and productivity have improved but no where near as much a computers. Because of this I would argue that optimizing for the programmer is far more important than optimizing for the machine and thus, should be a permissible interpretation of the "optimizing" in the pool.
|
|
|
|
|
Average source code is read about 10 times more often than it takes time to write it. And the average maintenance costs of software are also about ten times the amount of the costs of writing it.
From these facts alone, it should be clear, what code should be optimised for: for the reader and maintainer - and if you ever have inherited some foreign code that turned out to be a complete mess (and who has not) and tried to make sense of it, you know what I am talking about... 
If it comes to other kinds of optimisations: I do it only when there really is a problem in the field, or it is clearly foreseeable, but never ever proactively (i.e. I never have optimisations in mind when I initially write code, the only things I care for in that moment are simplicity and correctness).
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Agree with you 
|
|
|
|
|
Code simplicity and correctness gives better readability and maintainability.
If you think some other optimizations are needed, measure first to be certain of what, if anything, really needs to be optimized. Only then spend your time optimizing.
|
|
|
|
|
I call that Refactoring. Optimization ~= speed & efficiency; Refactoring ~= simplicity, understandability, maintainability. 
In my experience, the two are kind of counter-intuitive. Optimization of code for performance or efficiency usually results in something that is LESS understandable than code that is refactored for simplicity and maintainability. Its a continuous balancing act between acceptable speed and efficiency vs. acceptable code simplicity, understandability, and maintainability.
|
|
|
|
|
Jon Rista wrote: Refactoring ~= simplicity, understandability, maintainability.
True, if done correctly!
I usually write simple code from the start and don't do much refactoring.
My optimization steps usually revolve around implementing and profiling different algorithms. Some times a O(log n) algorithm is worse than a O(n) and it is not always obvious why. The best performing algorithms are not always the ones with the most complex, least maintainable code. That said, in general, I also tend to see a trade off between simplicity and performance.
|
|
|
|
|
PedroMC wrote: I usually write simple code from the start and don't do much refactoring.
I generally try to take the same approach (I'm probably the most fastidious programmer on earth...a stickler for proper structure, naming, ordering of code, commenting, etc.) However, when you work in a development shop where there are over a dozen dev teams of 5 or so people each, the volume of code that does not need regular refactoring is pretty small (sometimes the same subsystem needs to be refactord many times).
In my experience, most programmers are generally not concerned with code cleanlieness, clarity, simplicity, maintainability or performance...they just write code to meet needs of a specification and move on to the next task. In such a real-world environment, code reviews and refactoring are essential processes that help ensure that appropriate level of optimization vs. maintainability.
|
|
|
|
|
PedroMC wrote: If you think some other optimizations are needed, measure first to be certain of what, if anything, really needs to be optimized.
And when you do that, be sure to use the minimum supported hardware, not your dev machine
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
