|
When builds fail, that's just 'cause I'm letting the machine do the work for me. Not like in the stone ages where you had to "desk check" your code (punch cards) before turning it over to the operator. Back then, a compiler error was a *BIG* waste of time. The time spent desk checking was well worth it. Today, who cares? Let the machine figure out where the errors are.
|
|
|
|
|
If you can't be arsed to even try and write the code correctly in the first place, I can't believe that when it does compile cleanly it will do anything reasonable.
Software Zen: delete this;
|
|
|
|
|
I try to write the code correctly. But I'm certainly not going to waste my time "desk checking" for semi-colons, and other nonsense. The compiler will tell me the details, while I work on writing code that does what it's supposed to do.
Besides, I'm an old fart and I'm allowed to be lazy.
|
|
|
|
|
My point is that the devil is in the details:
if (condition1 | condition2);
{
Action5(0,Beta);
}See the problem?
Software Zen: delete this;
|
|
|
|
|
Well of course, you cleverly crafted a logic error disguised as a "compiler error".
Hell, I make many stupid mistakes, many are much worse than your example. But all in all, I try to write my code as carefully as possible. However, I have no objection to letting the compiler catch the nasties. I'm certainly not going to exert myself "desk checking" like I used to do with punch cards and paper tape. After all, the compiler spits out the results in a matter of seconds as opposed to getting my printout 45 minute later.
|
|
|
|
|
I totally agree with Abu Mami. These kind of errors are best detected by testing and debugging. If you're prone to such simple errors, then it's likely that you won't easily spot it in static analysis either. Testing is much more effective at that!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Letting the compiler catch syntactical errors while you 'worry about the big picture' isn't testing. It's laziness and a recipe for disaster. Competent software requires attention to detail. Incompetent software doesn't have it.
Software Zen: delete this;
|
|
|
|
|
I never said I only worry about the big picture. I don't. I did say that I spend (some of) the time I save by not brooding over code for debugging and testing. Maybe I should have been more clear: what I'm talking about is contemplating the effect of each statement on the variables, then running a test and verifying each indivdual step to confirm that the changes occur in exactly the way I expect. That still takes a lot of time, but nevertheless, it is orders of magnitude faster than emulating the computer in your head while brooding over some piece of code! Static analyisis is what tools do. Real programmers debug!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
The biggest problem which causes lower productivity is the programmer himself.
For example when he or she is reading articles or /and The Lounge 
I wonder how they missed that.
How unprofessional of them.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Simon O'Riordan from UK wrote: it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity.
I know, I laughed when I read that too, especially the "extra brainpower." We can't be contributing to global warming now, can we? Or heaven forbid, we ask our programmers to actually think
There's a lot of times when I make a major change to an interface and rather than figure out all the dependent classes I need to touch, I just I hit the compile button and let VS tell me where the fixes need to occur (of course, if I used something like Resharper, it probably could fix them for me, but I don't, so I have no idea.) Anyways, the point is, I use the compiler as a tool to facilitate in productivity.
Marc
|
|
|
|
|
I use the compiler in the same way when I change something that is not local to the function. The real productivity killers are the things that the compiler doesn't catch. Those that create exceptions later on (or even worse, silently fail and lead to incorrect results).
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Now we know why the ice caps are melting! 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Marc Clifton wrote: I just I hit the compile button and let VS tell me where the fixes need to occur
I do exactly the same. I find this very useful while refactoring.
I change variable types and names and don't let visual studio rename them so I can re-check every compile error if anything else needs to be changed.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Quote: extra time and brainpower
Luckily, I have a bucket of extra brainpower just over here by my spare time machine.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Would that be a spare time-machine or a spare-time machine. Because I think the latter would be much better.
|
|
|
|
|
If you had the former then you would also have plenty of the latter.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Ah but the former is only a spare one, so it's not getting much use.
|
|
|
|
|
If it's spare, can I have it? 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Now I want a spare-rib machine... 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
In related news, I understand that broken cars are really affecting the productivity of mechanics. And doctors are complaining that sick people are affecting their productivity.
|
|
|
|
|
As one of my college lecturers once said, code like you're stuck in the 1940's. In other words desk check it til the cows come home and ONLY then you compile. Treat the computer like it's a time share where you have to book several weeks in advance to get any run time to compile your program.
A little extra time during the design cycle works wonders for bug count (compile and logic bugs), amongst other things, such as code that will run until the cows come home like in financial institutions that have been running the same code on the same machines for 40 years or more. HUZZAH for stability.
|
|
|
|
|
Oddly enough, what you say is borne out by courses such as CMU's self-management course for softies. A detailed code walkthrough spots most errors before they get to the compiler.
However, the bugs that really slow you down are nothing to do with the compiler; testing bugs(inappropriate behaviour found in testing) occupy five times the span of compiler bugs, and if you want to get your LOC/Bug ratio down to acceptable levels, it is the testing bugs you should be aiming to get down.
And this is mostly about design.(If I remember right)
|
|
|
|
|
Simon O'Riordan from UK wrote: And this is mostly about design.(If I remember right)
Yup, and as I said, careful design will squish a lot of logic bugs as well. The bugs I find hardest to track down are what I refer to as 'incidental bugs'. Bugs that are normally not there but pop up from time to time when a user does something specific.
In my experience when I am trouble shooting code the user who is reporting the bug really doesn't know how to describe what they were doing when it happened. Very frustrating.
|
|
|
|
|
|
I wonder how long it will take for someone to produce a study that finds "sawing reduces carpenters' productivity!".
What concerns me more though, is the notion that compiler errors are a bad thing: Me, I *want* the compile to fail as often as possible, rather than have the program fail at runtime! I specifically design my code to fail at compile time if anyone uses it in an unintended way!
Also, when I write such code, I do test that the compiler really issues an error. I consider that a build success though, not a build failure!
Besides, I often use templates and other complex code constructs, and sometimes it simply takes less time to just do a quick compile rather than brood over the code for hours and wonder whether the syntax is actually fine. My brain isn't hard-wired to do syntax checks - so why shouldn't I use the compiler for that purpose?
Also I often try to eliminate #includes that I believe are no longer necessary (specifically in header files). Considering the convoluted mess of system include files, there is no way to find out without running the compiler!
Conclusion:
Compiler errors are a good thing! They're easy to fix, and safe me a lot of effort on code inspection. Anyone who builds compilers with the goal to reduce compiler errors has missed the point entirely! Compilers should be built to point out as many errors as possible. That's why we have strongly typed languages after all!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
