Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
On Tue, Mar 4, 2008 at 9:09 PM, Kristian Erik Hermansen <[hidden email]> wrote: > Interesting article. I like some of his points, but disagree with > dense code, even if I am perhaps still a teenager in his eyes. I suppose I qualify as a teenager in this respect (or even a toddler) but I kind of disagree with his view of commenting code. Too often, and his example seems to be one, the code being written (regardless of language) is a niche of it's own. No one will be reading it who hasn't been reading it for the equivalent of years. No one will be maintaining it except for the small group of robed jedi who already know the mindset of the original author as well as the subsequent construction crew who created this monolith to brilliance and efficiency. Additionally, most of the code we see today is as disposable as the punch cards of yesterday. Either the code is rock solid (as in his compiler example) or disposable modules that when they don't work, instead of being understood, they're deleted and new code put in it's place. I used to work with a guy who wrote code on a 24x80 screen. To him, whitespace was a waste. He could fit, oodles of code into that little space. A big piece of his work would be 80 cols wide and many many screenfuls of text. Sometimes broken at the right margin and picked up again at the left. By the way, he was brilliant. His code was a study in brilliant thinking and amazing implementation. Oh, his code sucked. Why? Because, it was completely unmaintainable. In most cases, it was faster and more economical to rewrite what he did in a much more simplistic form so that any junior engineer could maintain the code. I learned a number of valuable lessons from him. One was to try and see things as he did. I was and still am in my infancy in this regard. Another was "white space isn't a bad thing and it's free." Also, if my code is to be used beyond the time I have my hands on it, it must be maintainable by someone else who, because of any number of factors, doesn't have the time, ability, or desire to become one with the metacode and my mind. If it isn't, it's a one-of-a-kind demonstration of (some of) my skills akin to a woodworker spending ten years of his/her life creating a unique 'doo-dad' that has no purpose other than to demonstrate his/her skills. The code we are paid to produce isn't done (usually) for the sake of doing it. Our skills are applied to solve a problem that, if solved, means we make more money and the company grows and proposers. In doing that, if we don't make our work maintainable, we've failed. At my current engagement, I was chided by someone who felt that the shell script I'd done to solve a series of problems was juvenile, simplistic and in need of serious rewrite. I used discrete steps at each point in the code. I 'cut' data out of a program's output, I ran it through 'sort', and did a number of other processing steps. I turned to a non-UNIX geek, a guy we work with who supports MS-Windows machines, who's knowledge of UNIX is very limited and I asked him if he could understand what my script did. He read it for a few minutes and said "Yes". I then said "If you run it and it didn't work as you expected, what would you do to figure out why?" He pondered the question for a moment and said, "I'd look at the output of this step here. Then this step here. Then this step here. Until I found where things weren't as expected." I turned to the guy who started this conversation and said "I win." If the code is for my machine, under my control, and will never be used by someone else. Hell ya, I'll get creative and flex my mental muscles to do things unique and elegant. But if I'm writing code (scripts or otherwise) that will be read by someone else, I'll go back to the "juvenile" means of writing because I have found that this too is a skill that requires exercise. I will put comments in my code that include juvenile warnings about the value of a counter NOT being tied to the value of a specific buffer maximum or such. My commenting isn't just for "them", it's also for me because I am going to be dragged away to work on another problem and will have to return to this task and I prefer that after a context switch, I know where I left off. There are those who measure the code to comment ratio as a guideline to proper commenting. Me, my test is if someone else can do the work without me. So, call me juvinile, unsophistocated, inelegent but don't tell me that I waste time putting explainaitions into my code. Any one of us could get hit.... win the lottery and disappear from the planet. :) -- << MCT >> Michael C Tiernan. Is God a performance artist? EGO hack vivo quod ago accido. http://www.linkedin.com/in/mtiernan -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |