Do you have this experience?
-
Paul Watson wrote:
It seems to happen less now that I write test first.
That's a good point, and I would agree, I find I refactor less. One thing I still can't do is truly write the test first. I have to still implement at least a stub class because I think in terms of the "package", and that means coming up with the class name and at least an initial pass at the internal fields, public properites (C# centric) and method names. And at least that way, I can use Intellisense when writing the tests. How about you? Marc Pensieve
I try to be practical, not everything test first, while not forgetting that test first does catch silly mistakes in repetitive code. It is hard to define really and I am still refining the balance as I learn. I am not one extreme or the other though. regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
do -
When I go through and document my code, I often end up doing refactoring, things like adding parameter validation, exception handling, tweeks to improve code functionality, renaming variables/parameters/methods so that they are better defined. I find this to be true just about every time I go through and document the code. What about you? (Folks who don't document their code need not reply. ;) ) Marc Pensieve
All of the above, for sure. Especially when commenting code that has NO comments written by MUSH less experienced developers, who think every variable has to be i, j, k, or l. Were they FORTRAN programmers in a previous life or what :mad: I have to rename stuff just so I can keep track of what it is doing so I can add a resonable comment or produce documentation. People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
-
When I go through and document my code, I often end up doing refactoring, things like adding parameter validation, exception handling, tweeks to improve code functionality, renaming variables/parameters/methods so that they are better defined. I find this to be true just about every time I go through and document the code. What about you? (Folks who don't document their code need not reply. ;) ) Marc Pensieve
I write a comment in the code that I need to comment the code ... not because I have to (which I do) but because I should. But then by the time I'm done writing that piece, I feel less productive with the comments -- so I tend to procrasinate, and eventually my boss reminds me of it! So I eventaully do end up writing the comment -- just need the right motivation. :laugh: - Malhar
-
When I go through and document my code, I often end up doing refactoring, things like adding parameter validation, exception handling, tweeks to improve code functionality, renaming variables/parameters/methods so that they are better defined. I find this to be true just about every time I go through and document the code. What about you? (Folks who don't document their code need not reply. ;) ) Marc Pensieve
Marc Clifton wrote:
document my code
i never document or comment my code. i write code the is self-documenting.
-
Marc Clifton wrote:
document my code
i never document or comment my code. i write code the is self-documenting.
ahz wrote:
i write code the is self-documenting.
In my experience, that only goes so far. A well placed, valid comment can do wonders to help maintaining code, especially if someone new to the project or less experienced is working on it, or for yourself if it's a code you haven't looked at it in a year or two. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
Marc Clifton wrote:
document my code
i never document or comment my code. i write code the is self-documenting.
ahz wrote:
i never document or comment my code.
Well, in particular, I'm refering to xml comments around classes, properties, methods for auto-generating help documentation. Marc Pensieve
-
When I go through and document my code, I often end up doing refactoring, things like adding parameter validation, exception handling, tweeks to improve code functionality, renaming variables/parameters/methods so that they are better defined. I find this to be true just about every time I go through and document the code. What about you? (Folks who don't document their code need not reply. ;) ) Marc Pensieve
Certainly. I'll document a lot while desigining and writing the bulk of the code too, but there are those times where I lose patience with my own process and just need to see something work right now! Especially in those cases, taking the extra step to go through to document the code often leads to refactoring for a better overall design.
-
ahz wrote:
i write code the is self-documenting.
In my experience, that only goes so far. A well placed, valid comment can do wonders to help maintaining code, especially if someone new to the project or less experienced is working on it, or for yourself if it's a code you haven't looked at it in a year or two. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven WrightI couldn't agree more. For me, it's usually deciphering my intent in my own code a year later; I help myself alot to maintain and update code with those comments. I generally write clean code (from a "self-documenting" standpoint), but I agree - that only goes so far.
-
Drew Stainton wrote:
Waaaaay back in 1986 one of my prof's required us to write a user guide as part of the analysis/design. I took that (and the design docs) and developed documented stubs for a good portion of the code and then filled in the code to match the documented stubs. Wound up with pretty tight, well defined code blocks by doing it this way - forces you to stick with the game-plan.
I think this is the goal of any software product, but it also requires that the design goals do not change/evolve during the process. I have seen government projects try this, you spend a year planning and producing a ton (often litterally) of documentation on what you will do, and then spend the next 6 months editing it for the changes over the last year, then the next 3months editing it for the changes over the last 6 months... etc.... by the time you actually start developing to the documentation, you still have to take quarterly stops to rewrite code and update documentation. Or you stick to the documentation and make a product that will never be used. This obviously is not the case for all projects. I do believe there are projects that are best in the design&document first strategy, and there are those that require agile development. The first and hardest decision is figuring out which is which. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
ahz wrote:
i never document or comment my code.
Well, in particular, I'm refering to xml comments around classes, properties, methods for auto-generating help documentation. Marc Pensieve
Marc Clifton wrote:
xml comments
**bleagh** **blehch** **barf**