Oh yeah. I forgot about DDJ. I found it useful for grounding in prinicles, but not relevant enough to my everyday work to justify a subscription once my free year had run out.
cLive;-)
And with the death of Web Techniques magazine...
on
Webmonkey Closes its Doors
·
· Score: 5, Interesting
.. (a year or so ago) and The Perl Journal, there goes the rest of the teachers from my early coding days.
At least SysAdmin (even if pretty clueless sometimes as an entity) and Linux magazine are still worth reading. Both contain enough code to keep the old brain cells churning.
And it was so sad that Web Techniques turned into a load of old wank aimed at PHBs - that, and TJP were the only ones I happily paid for.
Anyone else got any (reasonably priced) recommendations for geek mags that still keep the ol' brain cells working?
The example i gave was off the top of my head. In the real world, for example, we've been dealing with a JavaScript HTML editor that has its own quirks (to say the least:). We do not have the time to learn enough OO javascript to perfect the code we're using. So we've had to hack how it works. Before presenting a page for edit, we have to remove certain elements and then re-insert them after edit. Without comments, we'd be returning to this code at a later date wondering *why* we're hacking it like this. Comments make it absolutely clear.
In reality crap code is used a lot because of deadline pressure. But that doesn't make it OK.
You're missing the point. If I can see what a coder *thought* they were doing, I can find their weaknesses easier and help them improve - rather than trying to second guess based purely on the code. I can spot inaccurate assumptions, illogical trains of thought and many other things that just don't jump out quickly from pure code.
Even if I can read and understand what your code does, if an issue comes up that needs fixing quickly (say, a security issue affecting 60,000 web sites), I need to identify where the issue could be as quickly as possible. By reading comments along with the code, it's a lot easier to spot mistakes made by a developer.
Here's another example. Let's say I'm chasing down a problem and I come to a regular expression that I think could be the issue. If the coder in question has commented it ( "Grab all URLs on the page that link to external sites", say) and I glance at the regular expression and see it doesn't do what the comment says it does, that sets alarm bells ringing. I can also gain an insight into what they were thinking when they coded the method.
In an ideal world, everyone would cover every possible issue and everything would be watertight. But, in the real world, I'm often dealing with work by coders with different strengths and weaknesses. And it's a lot easier to coach them on their thinking if I have some idea as to what's going on in their head.
I didn't mean to sound rude in my last post, but if you were working on my team, you would be expected to comment your code well. If you intend never to work with others and only maintain your own code, you could probably get away without commenting, but i wouldn't recommend it.
A few months ago I spent 3 days working on what ended up being 20 lines of code that recursively built a menu for a Template Toolkit page from a DB table. Although from reading it, it makes sense, I commented *every* line of those 20, explaining why I did what I did and what issues I was coding to avoid - and what I hit along the way. Even now I find the notes useful. Or perhaps you think you'd remember how and why you created a hashref of arrayrefs of hashrefs of arrayrefs for the data structure - and how that fitted in with the particular template - instinctively?
When taking on new team members (as we are at the moment:), I would be very wary of considering someone who doesn't comment.
But that's just me. And what I've found works in building Perl apps over the last 7yrs:)
s/\s+ # at least one space<br> \( # open parenthesis<br> .*? # as few characters as possible<br> \) # close parenthesis<br> //gx; # perform on every line and allow comments in regex
lameness filter won't let me space the comments neatly, but I'm sure you get the idea.
I'm not sure how "Healthy, readable code with sensible naming conventions and a clear structure" explains to you at a later date why you coded as you did. If you had to write something that looks out of place to deal with some legacy code you inherited, I'm sure you'd psychically pick that up just by glancing at the code. Or perhaps you go round naming vars something like $quirky_flag_to_pick_up_strange_situation_caused_b y_bad_code_in_package_X?
And what if someone less experienced than yourself has to maintain your code at a later date? Something that may seem obvious to you may be off of their radar.
If you never have to ask why and no one less intelligent than you ever looks at your code you either are very very lucky, very stupid or unemployed.
They're great. They help you to remember and comprehend code you wrote a while back. If you start a line with a "#" you can follow it with a comment.
If you're looking at code *you wrote* for over an hour without understanding it, you only have yourself to blame. Unless you're coding in brainfuck, I suppose.
Slashdot Mirror
Like those "sheets of clear plastic" Tom Had to load up before doing his hand waving voodoo? Great future view of storage technology.
lol
cLive ;-)
.02
cLive;-)
cLive ;-)
It'll happen - believe me :)
;-)
cLive
So, if they are fixing their position for search engine, I guess we can assume they did the same for operating system, eh :)
Or maybe they're trying to tell us something? ;-)
.02
cLive ;-)
Unless of course you're talking hardware DVD player - on Slashdot? Nah :)
.02
cLive ;-)
Oh yeah. I forgot about DDJ. I found it useful for grounding in prinicles, but not relevant enough to my everyday work to justify a subscription once my free year had run out.
cLive ;-)
At least SysAdmin (even if pretty clueless sometimes as an entity) and Linux magazine are still worth reading. Both contain enough code to keep the old brain cells churning.
And it was so sad that Web Techniques turned into a load of old wank aimed at PHBs - that, and TJP were the only ones I happily paid for.
Anyone else got any (reasonably priced) recommendations for geek mags that still keep the ol' brain cells working?
.02
cLive ;-)
Pork rinds perhaps? :)
.02
cLive ;-)
http://www.interactivetools.com/iforum/P15734/
;-)
cLive
cLive ;-)
He's only 75.
;-)
cLive
The example i gave was off the top of my head. In the real world, for example, we've been dealing with a JavaScript HTML editor that has its own quirks (to say the least :). We do not have the time to learn enough OO javascript to perfect the code we're using. So we've had to hack how it works. Before presenting a page for edit, we have to remove certain elements and then re-insert them after edit. Without comments, we'd be returning to this code at a later date wondering *why* we're hacking it like this. Comments make it absolutely clear.
In reality crap code is used a lot because of deadline pressure. But that doesn't make it OK.
You're missing the point. If I can see what a coder *thought* they were doing, I can find their weaknesses easier and help them improve - rather than trying to second guess based purely on the code. I can spot inaccurate assumptions, illogical trains of thought and many other things that just don't jump out quickly from pure code.
Even if I can read and understand what your code does, if an issue comes up that needs fixing quickly (say, a security issue affecting 60,000 web sites), I need to identify where the issue could be as quickly as possible. By reading comments along with the code, it's a lot easier to spot mistakes made by a developer.
Here's another example. Let's say I'm chasing down a problem and I come to a regular expression that I think could be the issue. If the coder in question has commented it ( "Grab all URLs on the page that link to external sites", say) and I glance at the regular expression and see it doesn't do what the comment says it does, that sets alarm bells ringing. I can also gain an insight into what they were thinking when they coded the method.
In an ideal world, everyone would cover every possible issue and everything would be watertight. But, in the real world, I'm often dealing with work by coders with different strengths and weaknesses. And it's a lot easier to coach them on their thinking if I have some idea as to what's going on in their head.
I didn't mean to sound rude in my last post, but if you were working on my team, you would be expected to comment your code well. If you intend never to work with others and only maintain your own code, you could probably get away without commenting, but i wouldn't recommend it.
A few months ago I spent 3 days working on what ended up being 20 lines of code that recursively built a menu for a Template Toolkit page from a DB table. Although from reading it, it makes sense, I commented *every* line of those 20, explaining why I did what I did and what issues I was coding to avoid - and what I hit along the way. Even now I find the notes useful. Or perhaps you think you'd remember how and why you created a hashref of arrayrefs of hashrefs of arrayrefs for the data structure - and how that fitted in with the particular template - instinctively?
When taking on new team members (as we are at the moment :), I would be very wary of considering someone who doesn't comment.
But that's just me. And what I've found works in building Perl apps over the last 7yrs :)
cLive ;-)
lameness filter won't let me space the comments neatly, but I'm sure you get the idea.
.02
cLive ;-)
I'm not sure how "Healthy, readable code with sensible naming conventions and a clear structure" explains to you at a later date why you coded as you did. If you had to write something that looks out of place to deal with some legacy code you inherited, I'm sure you'd psychically pick that up just by glancing at the code. Or perhaps you go round naming vars something like $quirky_flag_to_pick_up_strange_situation_caused_b y_bad_code_in_package_X?
And what if someone less experienced than yourself has to maintain your code at a later date? Something that may seem obvious to you may be off of their radar.
If you never have to ask why and no one less intelligent than you ever looks at your code you either are very very lucky, very stupid or unemployed.
.02
cLive ;-)
If you're looking at code *you wrote* for over an hour without understanding it, you only have yourself to blame. Unless you're coding in brainfuck, I suppose.
tch
cLive ;-)
Start now. It's gonna be a while before six is out - and even longer before companies will trust it in production environments.
And come over to The Monastery to get help when needed. A great resource for new (and experienced!) Perl hackers.
.02
cLive ;-)
What's it gonna be this week? :)
cLive ;-)
Or, to put it in simpler terms - "It's comedy, laugh".
.02
cLive ;-)
If not, and MySQL is your bottleneck, I'd be curious to know how it affects that when enabled.
.02
cLive ;-)
cLive ;-)
Lol, Oh crap. /me goes back to contemplating cigarettes again and makes a mental note not to comment on /. until the coffee kicks in...
cLive ;-)
With apologies to Monty Python...
Let's be pedantic here and say, "With apologies to Terry Gilliam and Michael Palin", since Jabberwocky wasn't a Python film.
Hmmm? Or, perhaps, the Beatles sung 'Imagine' and Genesis are responsible for that 'modern prog-rock classic' - "Groovy Kind Of Love".
Just to be pedantic, of course. I'm sure you knew it wasn't a Pyphon film, really :)
.02
cLive ;-)
cLive ;-)
And what's sad is that this is a real HTTP response code.
*sigh*
cLive ;-)