Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^2: "The Work of a Stranger ..."

by bitingduck (Deacon)
on May 10, 2012 at 14:54 UTC ( [id://969827]=note: print w/replies, xml ) Need Help??


in reply to Re: "The Work of a Stranger ..."
in thread "The Work of a Stranger ..."

I'm in much the same position-- I've been writing software for about 30 years, but never as my main job, sometimes for fun/entertainment and sometimes for work.

I often set code aside for months or years as I don't have time to work on it or get distracted by something else. I fortunately wrote some stuff in Turbo Pascal about 25 years ago (a Corewar implementation, fwiw) that I liked, and then went back to about a year later and tried to read. My reaction was "Wow, did I write this?". Even though it was broken into decent sized functions and they were labeled and lightly commented, I hadn't really explained anything at all of what was happening and why, and it took a long time to figure out.

I now tend to write for my future self, knowing that I'm not going to remember any of it: Start with comments to describe what the program is going to do at each step, write the program, describe what it's doing and why as a I go. If it operates on external data that might change, I'll put in notes of what it's expecting.

Replies are listed 'Best First'.
Re^3: "The Work of a Stranger ..."
by bulk88 (Priest) on May 11, 2012 at 05:18 UTC
    My idea of comments is, comments should be 1/3rd the size of the code they accompany. The comments should explain your design choice, potential future design choices you didn't do due to a lack of time, skills, research, profiling, benchmarking, performance, client demands, etc, all your rejected design choices and your rational for rejecting all of them. Someone, including you might come back and say "hey that works, you should've done it in the first place" at some later point. The whiteboard from the meeting you had with other devels, or the napkin or scratch paper you planed your design on is long gone if you come back to the code months or years later. The comments stay forever. The comments should, in some cases also summarize the behavior of the functions you didn't write but are using, if the docs of the function are extremely long (Microsoft), or are written with much "undefined" behavior and you are using that undefined behavior (Microsoft), or ridiculously short or none existent (auto generated garbage, examples are Azureus or Mozilla).

    Sadly in some places, programmers are encouraged, and its nearly a requirement to keep ones job, to write obfuscated comment-less unintelligible code to guarantee they have a job. Dead and unreachable code is also good. Exception handling code for impossible exceptions is good. If you to generate alot of work for youself, make a design policy, that 1 object/class's definition/interface can't take more than 1 screen, and the functions of that class in the code file can't take more than 2 screen fulls max and you wind up with inheritance charts that would take the surface area of a car to print on paper. It guarantees you will be employed since even if your client takes the code and gets "consultants" or contractors to look it over, they will return a quote of 100s or 1000s of hours or just cost plus to your boss. You salary looks alot cheaper to your boss suddenly.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://969827]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (2)
As of 2024-07-20 21:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.