The article provides some good style, but also some old habits that should probably be downplayed with modern languages. I wish I was taught good commenting techniques while at school. What I was told by nearly every professor boiled down to "Write everything twice. Once in the computer's language and once in human language."
A software engineer with enough experience learns that objects and functions should have a clear, singular purpose. The names of these functions and objects should convey this singular purpose. You can see why each of us has at some time probably wrestled with the concept of "self documenting code". We've all seen code like this and thought "Thank you, commenter. You must love to type."
I've found that once you have the skill to organize your thoughts enough that functions and object definitions don't ramble on forever, the documentation for each function becomes less important. I would assert that even without looking at the body of the above function, the function's name and scope does a very acceptable job of documenting what's going on.
With many small objects and many small functions (which is what I see many "good engineers" doing), the heart of your code's behavior lies more in how your objects interact. I've gotten more in the habit of creating macro-documentation just as much as micro. Instead of repeating myself with every line and function, I describe an overview for each tiny system. If you're looking at my object definition, you will see it prefaced with a comment block to the effect of this:
This object does ____. It may be used for purposes such as ____. It was not designed for _____ because _____. This object relies on these objects _____ for _____. For background on this solution/design pattern/general algorithm, see h t t p ://___________.
It's nice to be able to revistit some year-old system and have a single paragraph in a predictable location refreshing me on exactly what the hell is going on.
Also this entire topic is hilarious. Linking autism to geekiness? I can only assume most people have never genuinely encountered an autistic or person with aspergers.
Current estimates place someone with Asperger's Syndrome in every few hundred people. TFA doesn't do a good job of pointing out that Asperger's is what they call "high functioning autism", meaning that most of those with it can function and blend in with society if they choose to.
The correlation seems so reasonable to me, it's barely worth mentioning. I would speculate that a typical layperson definition of geek would be "An intelligent, but socially awkward person. A loner." Autism literally means self-ism. "One who is drawn into one's self."
Given the site you're reading now, I'd say odds are pretty good that you're working with someone that has some form of autism. They probably forgot to mention it to you.
Do you mean to imply that intelligence primarily serves to help us understand that which is crappy?
There are all kinds of good and bad in the Universe, observable at every intelligence level. To claim that sadness is the result of your ability to observe that which is bad is shortsighted.
The "ignorance is bliss" crowd tends to avoid answering "What intellignece level would provide me peak happiness?" Perhaps I should have "lifetime fast food manager" intelligence to find maximum joy. How about "still wearing diapers at 35" intelligence? Perhaps being comatose is my best option? After all, there are proven ways both physical and chemical by which I could permanently assume a lower intelligence level.
(I'd like to interject an apology for appearing to objectify those who fit in any of the above categories)
Brain chemistry aside, your happiness correlates to your emotional ability to process that which your intellect provides you. Whether you're bothered by missing SpongeBob or our Sun eventually going supernova, it's going to be your ability to balance that info with everything else that will determine how easily you can find happiness.
As Slashdot
mentioned earlier, a high percentage of Windows software is designed to only run as root.
I used to preach the same "Don't run as admin" line, but eventualy I had to face the reality that the only other choice is a broken machine. See for yourself how many programs try to modify a file in the "Program Files" directory branch through normal usage.
The only way to run Windows is as a god user. Anything else is expecting the software users to be more responsible then the software designers.
If you are developing for large, flexible software environments, The best coding practice is to hard-code logic for all situations, right? Write alternate code paths if that float is NaN or if that array size is negative. Catch, throw, and all that.
As your software environment and processing power shrink (think game consoles, PDAs, cell phones...or simply low-level code that can't afford the bloat), you have to make assumptions. It's no longer realistic to believe that every code module should handle every set of states and inputs like a perfect black box.
As you increase the lifespan of the code and the number of coders working with it, the usefulness of asserts also increases. When you write your brilliant, super-fast method that only works on normalized floats or ints with 22 significant bits, you'll know the calling code is following your rules... but in 6 months when the function becomes more popular without your knowledge, you're going to want it to blow up the moment it's misused.
I think Firefox is going to be the safer bet for a long time. Even if Firefox got an equal user base to IE, a spyware writer is going to enjoy more success targeting the IE users over Firefox users.
If you're counting on people not understanding or caring about security, virus protection and adware protection your target audience should be obvious.
The PS2 and GC are very similar systems, as far as overall capabilities are concerned.
GC has a faster processor. PS2 has more processors. GC is slightly higer-res. PS2 has more universal memory. When you weigh all the pros and cons, the systems are close to a dead heat.
"[A team that wrote a game for system A] is encountering a few problems porting [their game to system B]." Of course they are. That is the norm. I'm sure there were difficulties porting Jet Grind Radio from Dreamcast to Xbox.
"In conclusion, [said game] is the perfect hardware comparison between [system A] and [system B]." Bull.
2GHz when the Xbox was released? I'm impressed. The machine I was using to develop Xbox games at the time wasn't at 2.
I guess it's all going to boil down to whether your prediction is accurate about processor speeds stagnating. We have a solid 18 months or more to wait before PS3 is unveiled.
These are also early numbers. If in the coming year Sony sees that their system is going to be unusually ahead in processing power, they will likely loosen (cheapen) their manufacturing standards and clock down the chip.
I would imagine a large program to reap many tiny benefits from that adjustment.
A compiler can consider a variable with file scope to be never extern. Meaning that the usage of that variable is completely covered in the current compilation unit.
With that info, a compiler could decide to make a variable an inlined constant if its value is never modified. Or more frequently, the variable could be aliased or cached since the compiler would always know external function calls are never going to modify it.
Playing devil's advocate to most of the replies I've read so far, there are two benefits you could get from this approach.
If your language supports "static" in the file-scope sense, you could declare every global object as static and reap the compiler optimizations that come with that declaration.
If your language supports smart inlining, you could end up with code that has been inlined more effectively, since any code could be an inlining candidate regardless of location.
I can think of plenty of reasons to back away from the idea, but they'll flood in here without my help.
Re:Getters/setters bad?
on
Holub on Patterns
·
· Score: 3, Insightful
Read it again. He says that sub-classing is dangerous, not bad.
In the same sense that using a chainsaw is dangerous, but not necessarily bad.
So any one macine will only have time to infect five others. Problem solved!
A software engineer with enough experience learns that objects and functions should have a clear, singular purpose. The names of these functions and objects should convey this singular purpose. You can see why each of us has at some time probably wrestled with the concept of "self documenting code". We've all seen code like this and thought "Thank you, commenter. You must love to type."
I've found that once you have the skill to organize your thoughts enough that functions and object definitions don't ramble on forever, the documentation for each function becomes less important. I would assert that even without looking at the body of the above function, the function's name and scope does a very acceptable job of documenting what's going on.
With many small objects and many small functions (which is what I see many "good engineers" doing), the heart of your code's behavior lies more in how your objects interact. I've gotten more in the habit of creating macro-documentation just as much as micro. Instead of repeating myself with every line and function, I describe an overview for each tiny system. If you're looking at my object definition, you will see it prefaced with a comment block to the effect of this:
This object does ____. It may be used for purposes such as ____. It was not designed for _____ because _____. This object relies on these objects _____ for _____. For background on this solution/design pattern/general algorithm, see h t t p : //___________.
It's nice to be able to revistit some year-old system and have a single paragraph in a predictable location refreshing me on exactly what the hell is going on.
I wonder if Australia knows about the vile sexual imagery I was able to unlock in Mario Paint?
Why would anyone enforce spam?
Think of the children!
I was breaking it to them gently, emjoi.
Current estimates place someone with Asperger's Syndrome in every few hundred people. TFA doesn't do a good job of pointing out that Asperger's is what they call "high functioning autism", meaning that most of those with it can function and blend in with society if they choose to.
The correlation seems so reasonable to me, it's barely worth mentioning. I would speculate that a typical layperson definition of geek would be "An intelligent, but socially awkward person. A loner." Autism literally means self-ism. "One who is drawn into one's self."
Given the site you're reading now, I'd say odds are pretty good that you're working with someone that has some form of autism. They probably forgot to mention it to you.
There are all kinds of good and bad in the Universe, observable at every intelligence level. To claim that sadness is the result of your ability to observe that which is bad is shortsighted.
The "ignorance is bliss" crowd tends to avoid answering "What intellignece level would provide me peak happiness?" Perhaps I should have "lifetime fast food manager" intelligence to find maximum joy. How about "still wearing diapers at 35" intelligence? Perhaps being comatose is my best option? After all, there are proven ways both physical and chemical by which I could permanently assume a lower intelligence level.
(I'd like to interject an apology for appearing to objectify those who fit in any of the above categories)
Brain chemistry aside, your happiness correlates to your emotional ability to process that which your intellect provides you. Whether you're bothered by missing SpongeBob or our Sun eventually going supernova, it's going to be your ability to balance that info with everything else that will determine how easily you can find happiness.
I used to preach the same "Don't run as admin" line, but eventualy I had to face the reality that the only other choice is a broken machine. See for yourself how many programs try to modify a file in the "Program Files" directory branch through normal usage.
The only way to run Windows is as a god user. Anything else is expecting the software users to be more responsible then the software designers.
As your software environment and processing power shrink (think game consoles, PDAs, cell phones...or simply low-level code that can't afford the bloat), you have to make assumptions. It's no longer realistic to believe that every code module should handle every set of states and inputs like a perfect black box.
As you increase the lifespan of the code and the number of coders working with it, the usefulness of asserts also increases. When you write your brilliant, super-fast method that only works on normalized floats or ints with 22 significant bits, you'll know the calling code is following your rules... but in 6 months when the function becomes more popular without your knowledge, you're going to want it to blow up the moment it's misused.
Check back on this page around 2am. Better make it 3.
If you're counting on people not understanding or caring about security, virus protection and adware protection your target audience should be obvious.
GC has a faster processor. PS2 has more processors. GC is slightly higer-res. PS2 has more universal memory. When you weigh all the pros and cons, the systems are close to a dead heat.
"[A team that wrote a game for system A] is encountering a few problems porting [their game to system B]." Of course they are. That is the norm. I'm sure there were difficulties porting Jet Grind Radio from Dreamcast to Xbox.
"In conclusion, [said game] is the perfect hardware comparison between [system A] and [system B]." Bull.
I guess it's all going to boil down to whether your prediction is accurate about processor speeds stagnating. We have a solid 18 months or more to wait before PS3 is unveiled.
These are also early numbers. If in the coming year Sony sees that their system is going to be unusually ahead in processing power, they will likely loosen (cheapen) their manufacturing standards and clock down the chip.
Why does "18 months" sound familiar?...
It's less of a leap when you consider the speculated release date of PS3.
A compiler can consider a variable with file scope to be never extern. Meaning that the usage of that variable is completely covered in the current compilation unit.
With that info, a compiler could decide to make a variable an inlined constant if its value is never modified. Or more frequently, the variable could be aliased or cached since the compiler would always know external function calls are never going to modify it.
If your language supports "static" in the file-scope sense, you could declare every global object as static and reap the compiler optimizations that come with that declaration.
If your language supports smart inlining, you could end up with code that has been inlined more effectively, since any code could be an inlining candidate regardless of location.
I can think of plenty of reasons to back away from the idea, but they'll flood in here without my help.
In the same sense that using a chainsaw is dangerous, but not necessarily bad.