Programmer's Notes

[MrKowz]

We haven't had a random discussion thread in a bit, so here goes!

Do you jot down anything or have any particular procedures you follow when programming something out of the norm? Sure, a lot of us can throw out macros that have a loop and some basic logic off the top of our head, but what about when you have a really complex task?

I find myself sometimes drawing a small flowchart for the loops that have many different paths. Or sometimes, if I'm trying to write a formula that I know is going to be big/complex, I'll write out in words what I am trying to do (putting space between each line) and then try to translate it into crude Excel language. But for the most part, I just start writing code, and read/re-read/correct it as I go.

 

[RobMatthews]

Arrgh. Just lost ten minutes worth of typing due to bumping the "back" button on my mouse. And forward didn't bring it back. Oh well.

Short story- grade 9 or 10 teacher told us to flowchart, then pseudo-code, then code.
I tend just to code, sometimes doing pseudo-code prior to a complex task, and flowcharting for the real difficult stuff.
I don't comment enough, but i do use meaningful variable names.

Edit:
@ruin3r: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live

 

[Taul]

Generally I just write the code. It’s only when I get stuck, I go back and either write it in words or scribble out some crude flow chart. But most of the stuff I do is simple enough to code straight away.

I do annotate all my code; mainly because I have a poor memory, and if someone asks me to change something, I rely on the annotated notes to save me the pain of learning it all again.

I have spoken to professional coders (well contract guys anyway) who keep their library of code annotated, but remove the annotated notes before publication. They take the view that it took ages to learn and they are not giving it all away for nothing.
I can’t blame them really, they have to protect their income.

 

[sous2817]

I always start off with the intention of "planning, pseudo-code, more planning, well-commented code".

The reality is...deadline is too short to do anything other than sit down and chug away. I have been better about commenting though. The amount of times I've come back to something a few months later and said "Why the flip did I do it like that, this way I just learned is way more efficient". Proceed to make a ton of undocumented changes, rerun code and the realize "oh...so THAT'S why I did it that way!"

One of these days I'll be able to talk my manager(s) in to the benefits of planning and design sessions before getting started.

 

[SydneyGeek]

I try to make it as modular as possible, for big routines.
Get a chunk to work, then go to the next (often a separate Sub). It's easy to daisy-chain the calls when you want to run the whole thing.

For each routine, if it's got more than one or two logic steps, I create comments before I code, then write each section.

As for removing comments before going live; I'd shoot myself in the foot if I did that, given that I usually maintain the code anyway.

Denis

 

[VoG]

Plan and document code? Bizarre

 

[TinaP]

Mostly, I just sit down and code, but I pseudo-code and flowchart the more complicated stuff just to make sure I know what I want to do. Modular coding helps by breaking down the task to small steps.

As far as commenting, I used to code with very few comments, but like the earlier commenters, I couldn't troubleshoot the code. On two recent occasions, I had to totally rewrite the code for two macros. One was an uncommented mess with nested ifs six deep in spots. When I tried to fix it, I ended up with non-functional code and three hours of my life that I'd never get back. The new code is fully commented. Lesson learned.

 

[JazzSP8]

If its something out of the ordinary I tend to the write the code in Pseudo-Code mixed with real code in Notepad before copying it into the VBE; that way it sort of builds itself in my head as I write round it, not the normal approach I know but it tends to work for me...

As far as commenting goes - Then, same as above - When I was first 'taught' about commenting I more or less ignored it until *that* time comes when you need to go back to something you've done a year or so ago and you don't have a clue what you've done, like most above all my code is now commented and commented well.

(I like to think that I was a much cleverer man in those times as I don't understand it anymore, somewhere inside me knows that this isn't the case though...)

Weird thing is, I love flow charts for anything apart from programming .. Give me a copy of Visio and I'll flow chart anything apart from a computer programme...

 

[Jon von der Heyden]

Obviously depends on the project, but using classes tends to help me compartmentalise the different elements. I tend to think what objects I need, what properties and what methods. Then I go from there...

 

[diddi]

the @SydneyGeek method is a carbon copy for me. perhaps its the .au teaching methods from the era. i started on Fortran back in the days of marksense cards and went through the non-visual stage of 20kLOC abominations, all subbed out to run on low RAM systems.

the other thing i do is keep a library of solid code fragments that i recycle over and over. and recently i have started collecting entire userforms that i can plonk into new projects which i have found really helpful.