Amazement - The Goat Version Everytime I think I've seen it all, I accidentally kick over another turd of that one special co-cattle of mine and find myself staring in painful amazement as I attempt to properly bury the schizophrenic droppings that is his stool. No real food, still bound yet digested books shat upon older still bound yet digested magazines, no green vegetables at all, and a mess in the first place.
The irony is that in order to rebury the abomination (that's what I'm trying to do at the moment) I have to understand what the old goat ate. Oh, the stench. Days like this one make me wish I was a programmer or an engineer.
::giggle::
~Malmuira
Edited on Jan 28th 2003, 17:35 by malmuira
Mulligan
· 6 years ago
Start an obfuscated PHP contest, put him forward as the only submission explaining that the first prize is a good beating and then ensure he wins. He'll get the point eventually. There's always place for dirty but useful hacks and indeed, hacks on old hacks. But when time expended understanding said hackage exceeds cost of development or even comedy factor, it's time for a change.
And goats are good.
Carlo Zottmann
· 6 years ago
LOL - Malmuira, you're probably right. ;)
Mull - I doubt he would, really. :/
entipy
· 6 years ago
I was going to make a "goat" comment of some sort, but after reading those two comments, that idea is just basically moot.
(It's got to be pretty damn bad to want to be a goat, though. :/ )
Hooloovoo
· 6 years ago
resists temptation to bring up an old goat joke... barely.
About obfuscated code: There was a web designer that used to work with me here who, one day, jokingly remarked "Fear my code, biotch!" And with good reason. His HTML still haunts me to this day.
I've re-written a few of the pages he did that I have to update on a semi-regular basis, but I dread the days when I have to go in and make changes to his content or code. (Un)fortunatley it doesn't happen often enough to justify entirely rebuilding those sections of our website. (Some day, but not yet... sigh)
entipy
· 6 years ago
[Quote] His HTML still haunts me to this day. [Quote]
I can only hope no one ever says that about my HTML code.....
enid
· 6 years ago
I understand you concern, entipy, BUT....
While I agree all Code should be as clear and well notated as reasonably possible, it is also important to consider what the code is for.
If you are working in a large organisation where you know someone else will eventually inherit your work and will have to understand what you have done, then clearly notation is very important.
Me - well I work for myself. Whilst there are exceptions, 90% of the time I am the only person who will be working on my pages / databases.
Now I could add a couple of hours to each job and fully document them, but the usefulness of notation is limited, my clients will not want to pay for time which is not directed at making their software work, and if I'm a bit bloody about it I am not going to bend over bakwards to make it easier for someone else to take over my projects.
As for some mythical code monkey laughing at my work in the future. I really don't give a s**t. As long as it works, it is reliable, it is appropriately effecient and it is delivered cheaply and on time, both I and my clients are happy.
[edit] syntax (possibly an unnecessary notation?)
Edited on Jan 29th 2003, 17:47 by enid
Carlo Zottmann
· 6 years ago
[Quote] While I agree all Code should be as clear and well notated as reasonably possible, it is also important to consider what the code is for. [Quote]
True that. In my case, it's for a big-ass TV station website and a team-based environment - so IMHO at least clean code is in order. Hell, we're pros, so most of us don't need much documentation. If the code is good enough, you can just read thru it to understand what's it supposed to do.
But no, there're not even in-code comments...
entipy
· 6 years ago
Perhaps I misunderstand what "clean" code is... Is it clean as in easily understandable? or clean as in well-noted? or both?
Spam
· 6 years ago
Clean code is code that is easily understandable to one proficient in the language, as well as being aesthetically pleasing. This can mean that good algorithms are used, the right level of abstraction is used, there is little or no redundant code, the problem is well-modeled, etc.
entipy
· 6 years ago
Ok....
line breaks at the beginning or end of the line??
I used to do them at the end.. then at the beginning.. and now it just depends on the flow of everything else
Hooloovoo
· 6 years ago
[Quote] Now I could add a couple of hours to each job and fully document them, but the usefulness of notation is limited, my clients will not want to pay for time which is not directed at making their software work, and if I'm a bit bloody about it I am not going to bend over bakwards to make it easier for someone else to take over my projects. [Quote]
Have you ever had to revisit a project to make tweaks or fixes? Even if the purpose of the code is clear when you write it, a few months/years later it might not be. A well placed comment or two can really help you remember what you were trying to do and why you used a particular construct to do it.
[Quote] Perhaps I misunderstand what "clean" code is... Is it clean as in easily understandable? or clean as in well-noted? or both? [Quote]
In many cases, its both.
[Quote] Clean code is code that is easily understandable to one proficient in the language, as well as being aesthetically pleasing. This can mean that good algorithms are used, the right level of abstraction is used, there is little or no redundant code, the problem is well-modeled, etc. [Quote]
That's a great definition, Spam. I would also argue that part of what makes code easily understandable is sufficient, yet concise documentation.
ethal
· 6 years ago
My code sucks. I can never be bother to intent it so you know where all the info goes and it is a real mess but I work for myself and I am the poor sod who has to work out why the hell I did it that way 4 months ago. dont ever look at my code Gossip :)
Mulligan
· 6 years ago
Gossip's code glows. I downloaded GLUE a few weeks back, unzipped the tarball and opened one of the source files in TextPad. Man, you shoukd have seen it. Each line had this soft, angelic glow around it. And my body filled up with warmth and a sense of well-being.
Mulligan's eyes well up...
Carlo Zottmann
· 6 years ago
ROFL
Rrrriiiiiiiight.... ;)
enid
· 6 years ago
[Quote] Have you ever had to revisit a project to make tweaks or fixes? Even if the purpose of the code is clear when you write it, a few months/years later it might not be. A well placed comment or two can really help you remember what you were trying to do and why you used a particular construct to do it. [Quote]
Yep. Many times. Most of what I do is database stuff, and I find almost without exception that if the db schema is right (ie simple / logical and normalised) the code is always simple.
Enids Law of Recidivistic Development: "If its hard to code, you probably have your schema wrong!"
That said, what I was really trying to say to entipy is:
Don't get too hung up on "clean" code just yet. Yes it is useful, and in some cases its critical, but get in there and write some scrappy stuff that works without worring about how clean it is. Clean can come later (if necessary). The only thing you must avoid is not even trying because of a fear that people will laugh at your "unprofessional" efforts...
entipy
· 6 years ago
LMAO Mulligan
enid, I'm not too hung up on it... :) However, it is difficult sometimes for me when I go back and look at previous projects.... so, I have decided to start making my code neat again. (or trying to, anyway)
Hooloovoo
· 6 years ago
[Quote] I have decided to start making my code neat again. (or trying to, anyway) [Quote]
That's all anyone can really do. :)
entipy
· 6 years ago
:)
malmuira
· 6 years ago
At this point, I have ceased to understand much of the conversation.
So I'm going to go to the virtual kitchen and bring you guys some beer and chex mix or something.
All Comments
Amazement - The Goat Version
Everytime I think I've seen it all, I accidentally kick over another turd of that one special co-cattle of mine and find myself staring in painful amazement as I attempt to properly bury the schizophrenic droppings that is his stool. No real food, still bound yet digested books shat upon older still bound yet digested magazines, no green vegetables at all, and a mess in the first place.
The irony is that in order to rebury the abomination (that's what I'm trying to do at the moment) I have to understand what the old goat ate. Oh, the stench. Days like this one make me wish I was a programmer or an engineer.
::giggle::
~Malmuira
Edited on Jan 28th 2003, 17:35 by malmuira
And goats are good.
Mull - I doubt he would, really. :/
(It's got to be pretty damn bad to want to be a goat, though. :/ )
About obfuscated code: There was a web designer that used to work with me here who, one day, jokingly remarked "Fear my code, biotch!" And with good reason. His HTML still haunts me to this day.
I've re-written a few of the pages he did that I have to update on a semi-regular basis, but I dread the days when I have to go in and make changes to his content or code. (Un)fortunatley it doesn't happen often enough to justify entirely rebuilding those sections of our website. (Some day, but not yet... sigh)
I can only hope no one ever says that about my HTML code.....
While I agree all Code should be as clear and well notated as reasonably possible, it is also important to consider what the code is for.
If you are working in a large organisation where you know someone else will eventually inherit your work and will have to understand what you have done, then clearly notation is very important.
Me - well I work for myself. Whilst there are exceptions, 90% of the time I am the only person who will be working on my pages / databases.
Now I could add a couple of hours to each job and fully document them, but the usefulness of notation is limited, my clients will not want to pay for time which is not directed at making their software work, and if I'm a bit bloody about it I am not going to bend over bakwards to make it easier for someone else to take over my projects.
As for some mythical code monkey laughing at my work in the future. I really don't give a s**t. As long as it works, it is reliable, it is appropriately effecient and it is delivered cheaply and on time, both I and my clients are happy.
[edit] syntax (possibly an unnecessary notation?)
Edited on Jan 29th 2003, 17:47 by enid
True that. In my case, it's for a big-ass TV station website and a team-based environment - so IMHO at least clean code is in order. Hell, we're pros, so most of us don't need much documentation. If the code is good enough, you can just read thru it to understand what's it supposed to do.
But no, there're not even in-code comments...
line breaks at the beginning or end of the line??
I used to do them at the end.. then at the beginning.. and now it just depends on the flow of everything else
Have you ever had to revisit a project to make tweaks or fixes? Even if the purpose of the code is clear when you write it, a few months/years later it might not be. A well placed comment or two can really help you remember what you were trying to do and why you used a particular construct to do it.
In many cases, its both.
That's a great definition, Spam. I would also argue that part of what makes code easily understandable is sufficient, yet concise documentation.
Mulligan's eyes well up...
Rrrriiiiiiiight.... ;)
Yep. Many times. Most of what I do is database stuff, and I find almost without exception that if the db schema is right (ie simple / logical and normalised) the code is always simple.
Enids Law of Recidivistic Development: "If its hard to code, you probably have your schema wrong!"
That said, what I was really trying to say to entipy is:
Don't get too hung up on "clean" code just yet. Yes it is useful, and in some cases its critical, but get in there and write some scrappy stuff that works without worring about how clean it is. Clean can come later (if necessary). The only thing you must avoid is not even trying because of a fear that people will laugh at your "unprofessional" efforts...
enid, I'm not too hung up on it... :) However, it is difficult sometimes for me when I go back and look at previous projects.... so, I have decided to start making my code neat again. (or trying to, anyway)
That's all anyone can really do. :)
So I'm going to go to the virtual kitchen and bring you guys some beer and chex mix or something.