Psuedo Code
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Nope. I think the comments should reflect the state of the software, so I hash things out separately - the failed directions are as important as the solution, so I don't forget and make the same mistakes again when I review the software in six months time and think "why the heck did I do it that way?"
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
It's called "documentation", real programmer don't do it.
Its the man, not the machine - Chuck Yeager If at first you don't succeed... get a better publicist
The job ain't done until the paperwork is finished...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I used to... Nowadays, if I have to work out a complicated algorithm, I'll pop open a notepad and outline the general flow (Not even pseudo-code)... But that rarely makes it into the code comments. I do those after I get it working.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I used to do that a lot, but not any more. OOP guidelines are to favour shorter methods that do just one job, so really there's not much need for pseudocode comments of something that small. Hopefully, the higher-level methods call lower-level methods with good enough names that the intention is clear. Of course, where algorithms are important, I may still pseudocode, but that's typically on a scrap of paper by the side of the PC. The only place I comment nowadays is generally where: (i) The code does something non-obvious, such as a workaround for a bug, or... (ii) The code exposes an API callable from other modules, possibly written by other dev's - I don't expect them to root through my code to determine how to use it. Again, well chosen method and parameter names can help a lot here.
-
It's called "documentation", real programmer don't do it.
Its the man, not the machine - Chuck Yeager If at first you don't succeed... get a better publicist
There is not a single line of documentation in the thousands of lines of code in our production software. I got here 6 months ago, so it is out of my control.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I do that in paper before putting myself in front of the computer... Even there are tools like Visio and others I'm faster doing it by hand... Then at the end and depending on the complexity I make the final flowchart in visio and store that in the documentation folder or if it is easier I use that approach you are describing. Whichever is the choice it is always a must to put lots of comments in the code.
[www.tamelectromecanica.com] Robots, CNC and PLC machines for grinding and polishing.
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
wizardzz wrote:
How many of you hash out the logic of what you are about to write in a comment, then code it?
I actually write the basic logic on paper and mess with it there and then I code it. I can see the events and logic flow in my mind and I know how it will behave, to a point, then code it and inevitably debug it. I once read that if you have to describe in detail what your a function or other code does in comments then you have failed your job as a coder. Your code should be clear as to what it does and how it works in a general level. Now, this was a Microsoft developer that said this so take it for what it's worth. :) I see his point though. If you have a function
ProcessMemberIDwhy do you need a comment that says: This function processes member id's. Pretty silly actually.----------------------------- Just along for the ride. -----------------------------
-
There is not a single line of documentation in the thousands of lines of code in our production software. I got here 6 months ago, so it is out of my control.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
got ya beat, there are 5 comments in the thousands of lines of code in our software..... one of which I paraphrase with single quotes
" 'these things must stay in this order' or bad things will happen"That's the best comment in the whole thing I've been here 3 months so it was out of my control. Going forward however its all on me, I must make sure not to be a hypocrite :laugh: :laugh:Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning. A crisis on your part does not constitute one on mine.
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
I used to do that a lot, but not any more. OOP guidelines are to favour shorter methods that do just one job, so really there's not much need for pseudocode comments of something that small. Hopefully, the higher-level methods call lower-level methods with good enough names that the intention is clear. Of course, where algorithms are important, I may still pseudocode, but that's typically on a scrap of paper by the side of the PC. The only place I comment nowadays is generally where: (i) The code does something non-obvious, such as a workaround for a bug, or... (ii) The code exposes an API callable from other modules, possibly written by other dev's - I don't expect them to root through my code to determine how to use it. Again, well chosen method and parameter names can help a lot here.
Rob Grainger wrote:
(i) The code does something non-obvious, such as a workaround for a bug, or...
Agree.
----------------------------- Just along for the ride. -----------------------------
-
I do that in paper before putting myself in front of the computer... Even there are tools like Visio and others I'm faster doing it by hand... Then at the end and depending on the complexity I make the final flowchart in visio and store that in the documentation folder or if it is easier I use that approach you are describing. Whichever is the choice it is always a must to put lots of comments in the code.
[www.tamelectromecanica.com] Robots, CNC and PLC machines for grinding and polishing.
Joan Murt wrote:
I'm faster doing it by hand...
:thumbsup:
----------------------------- Just along for the ride. -----------------------------
-
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
if it's a long process, sometimes i'll comment each step first and then fill in the code. it rarely survives the first pass, though. unless i'm following an algorithm from a cookbook, just typing the code brings up issues i didn't consider when writing the comments.
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I do it... it makes me think of things more generally rather than getting caught up in details off the back... it makes the actual code writing go a lot faster later on since I don't have to rethink "what's next?".
-
I do it... it makes me think of things more generally rather than getting caught up in details off the back... it makes the actual code writing go a lot faster later on since I don't have to rethink "what's next?".
I feel the same way. It's odd that there seems to be a little bit of dissonance between grasping the logic completely in my mind, and finding the best way to code it. I do tend to code most efficiently when I'm following my own well thought out directions.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
-
got ya beat, there are 5 comments in the thousands of lines of code in our software..... one of which I paraphrase with single quotes
" 'these things must stay in this order' or bad things will happen"That's the best comment in the whole thing I've been here 3 months so it was out of my control. Going forward however its all on me, I must make sure not to be a hypocrite :laugh: :laugh:Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning. A crisis on your part does not constitute one on mine.
gavindon wrote:
" 'these things must stay in this order' or bad things will happen"I like that :thumbsup:
Und wenn du lange in einen abgrund blickst, blickt der Abgrund auch in dich hinein.
-
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Only if it's really complex, or if I'm making an initial run coding a class and putting method stubs in, and even then, it's more to help me remember my intent than to flesh out the code.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
How many of you hash out the logic of what you are about to write in a comment, then code it? Realistically I haven't done this in a while, but just did so I could go over it in writing before coding it all. It is something I did when I was a beginner much more often. How many of you guys find yourself doing this still?
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I'm a VB.net programmer: my pseudo-code is also my production code :rolleyes: I also add comments when I'm doing something odd or complex. The alternative is spending hours trying to remember what I was thinking when I wrote the code, then hours more trying to explain it to the new guy.
