Today in the news: Why Builds Fail
-
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; -
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.
-
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; -
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.
-
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
Latest Articles - APOD Scraper and Hunt the Wumpus Short video on Membrane Computing Hunt the Wumpus (A HOPE video)
_
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
-
This absolute gem, quote: "When builds fail, due to compilation errors, it requires programmers to take extra time and brainpower to find and fix the problem, reducing their productivity." Yes. Waiting for the computer to boot, that too. And sleeping for 7 hours at night. And eating, and going to the coffee machine. All these things. Did I mention design? Coding? These two REALLY use up that there productivity. :laugh:
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)
-
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)
Hear hear. Not to mention meta-programming. Who could remember all those rules perfectly?
-
My point is that the devil is in the details:
if (condition1 | condition2);
{
Action5(0,Beta);
}See the problem?
Software Zen:
delete this;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)
-
Ah but the former is only a spare one, so it's not getting much use.
If it's spare, can I have it? :-D
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)
-
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; -
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)