How often do you like to compile?
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
I used to compile constantly, but I also used to be young and made lot's of mistakes and compiling felt safe. Nowadays I just type out whatever I'm working on in a single go and rely on IntelliSense to catch my mistakes. In general, I don't have compiler errors anymore on a day-to-day basis.* I never liked working through compiler errors one at a time. I'm IntelliSense-4-life now. * I now get compiler errors when it's 2AM and I'm drunk. :java:
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
Like many others, frequency of compilation depends on what I'm doing. If I'm writing a processing routine that has no visual component, I probably won't compile until I've completed the first pass on it. This could be hours or days between compilations. If I'm doing front end work? Much more frequently, as "what you think you're gonna see is not necessarily what you're gonna get".
-
With intellisense and other IDE features, compiling (though not the meaning it used to have) is pretty much unnecessary until you're ready to test. And of course in duck-duck-run languages, there is no such thing as compiling.
Latest Articles:
Fun Exploring Div and Table UI LayoutLooking at some of the responses, I probably should have asked "How often do you compile/test". It was really to get more insight into how often other developers stop coding to check their work.
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
It's not about compiling, per se, but about testing. Some people like to write an entire chunk of functionality, then do all their testing, iterating at that level when they find the problems. Some, (myself included), like to write a small chunk of the overall functionality, test it thoroughly, then move on to the next small chunk. This approach probably means less unit-level testing, but more integration testing, I suppose.
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
Think everyone develops their own habits naturally for me, as a Linux C/C++ developer, if it's maintenance I am doing fairly frequently as I am making my code changes. We work with eclipse and CMake so it's easy just to hit the build button. But when I am adding a new feature and looking at my class diagrams (Dia, visio type). It normally happens at the end after I code a nearly complete class and add it to the CMakeList.txt file. Think if people created well fleshed out class diagram first, it would happen less often when you start coding it, but then more often afterward.
-
Back when I started, the answer would be 'every fortnight'. It took that long for your coding sheets to be sent away, mispunched, and a program listing with error messages to be sent back. So, you'd rewrite the mispunched rows, sent it off, wait a fortnight to see if it had been repunched correctly. Sometimes it would take a couple of months before you got a program that was what you had written. Then you can move on to the next stage. Needless to say, desk dry running was a lot more rigorous - a potential bug found at that stage could save weeks of waiting. The problem with this is that you tended to put too much code into each iteration, so when you got anything usable back, there were too many places to check (and it was so long ago when you wrote it that even the copious comments weren't helpful. That habit has been hard to break. Even when we punched our own cards and submission / turnround times were only a few days, compiling was seen as a milestone (or a millstone). I had to train myself to write small blocks of code, test, write the next bit, test, repeat ad nauseum.
Fortnight? goo! In school it was drop the deck off ( we punched our own ) ( and drew lines on top as "hex marks" ), and pick up the printout next day or so. ( Of course, waiting a fortnight would have made class _difficult_. ) When I started work, we had ( Bruce and I ) the machine to ourselves. I atemped to compile about 3 times - about 10 lines of Fortran. Failed in the library. Found that no-one else had any luck with the compiler yet either. ( PDP11, 16K WITH the integer multiply / divide unit ). Still punching cards, but no compile, assemble, test, ( CPU switches and lights ) sometimes patch at the CPU.
dave of eves
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
When I was young and unexperienced, it was more like a lottery whether my code would run or crash. Knowing that on a subconcious level, I didn't want to be reminded of how unexperienced I was, rarely compiled and never debugged unless there actually was a bug. But finding the bugs I produced sometimes took more than twice as much time as it took to produce them, and I believe some of them were never even found by anyone at all. Today, with more than 20 years of experience, when writing production-level code (so this doesn't go for clickdummies etc.), I want to be aware of my code quality at any time, which means I compile and run *very* often and execute all newly written code in the debugger step by step, having a look at the state of all objects and local variables involved. So lottery no more! This significantly decreases my development speed, by let's say factor 3, while increasing my code quality by factor 2 only. But(!!) economically, this is still sensible bc it spares the quality assurance and technical support people some effort and prevents customers from running away due to poor code quality and frequent crashes.
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
It depends, but in general, as soon as all the related changes needed in order to have a successful compile have been made, I try compiling it. In well designed code, that time usually comes very quick as very little code needs to be changes. In really poorly designed code, it might be a week.
I live in Oregon, and I'm an engineer.
-
Someone here, I believe it was honey the codewitch, mentioned they "develop very iteratively". It made me think about styles of coding vs. debugging. Where I work, some people tend to code much more than others before compiling. I like to err on the side of caution- compiling much more often to see that what I think I did, actually worked the way I think it did. Maybe some of it is confidence in your code skills? You can certainly code more if you don't check your work every two seconds, but if you embedded a bunch of bugs, they may be hard to find if you wait too long. ...Just curious what you guys think? Is it a matter of style, or is there a right or wrong way? How often do you like to compile?:confused:
Just like my saves, early and often. ;)