What's really upsetting about SOPA is not the content of the legislation (there has been even nastier stuff proposed in the past, and expect worse in the future). It's the naked and unapologetic way in which the RIAA and MPAA have declared that they own the US House of Representatives. It's not new that our politicians are corrupt, spineless and clueless (indeed, the US is actually far less corrupt than most nations), but the corruption that we do have can cause so much damage. Even China can't slam the world as hard as the US, in this arena (that may eventually change).
Sadly, I doubt there's evidence that can be used to actually convict them.
However, the story is an object lesson on the dangers inherent in modern social networks.
If THESE folks can get found out (note that some of them were actually "ratted out" by their own Significant Others), then the normal mensch on FaceBook is pretty much screwed.
Good points.
As a manager of a C++ shop, and as a person that writes A LOT of Web and iOS stuff, I have quite a bit at stake here.
My team (the job that pays my salary) doesn't do enough documentation.
That's not their fault, that's mine. I haven't put enough priority on docs, and I haven't given documenting the schedule padding it deserves.
That being said, I need to come up with creative ways to encourage documentation.
Good process helps. A set of rules, heuristics and templates, spelling out decent coding, is helpful. It is, indeed, possible to write "self-documenting" code, but most folks won't do it, and that fox may not be worth the chase. The "sweet spot" seems to be a combination of decent coding practices, consistent style, and small, concise comments, sprinkled throughout the code.
Another way is Doxygen. It works marvelously well, and I use it to create the API docs for my Web and iOS stuff (the stuff that doesn't pay my salary). As my Web stuff is public domain and open-source, it needs documentation, quite badly. I have used Doxygen to produce some truly extensive stuff.
However, Doxygen produces only technical/detailed docs. We still need the "big picture" documentation and the structural stuff.
That needs to be written separately. By a good tech writer.
Many engineers are terrible (I mean God-awful) tech writers. In many cases (including docs that I have written), the documentation is actually WORSE than no documentation. I have written a huge amount of documentation that no one reads, because my information architecture sucks, and because I am the epitome of "prolix." I am in the process of re-evaluating a lot of my documentation, and seeing if I can get other folks, better at writing, to help out.
20 line functions?
Sure, I'm sure that exists...somewhere. I've been writing code for about 30 years, in dozens of languages from hex machine code to PHP (with the lions' share being C++), and I've yet to see anything outside of an academic context follow rules like that.
I once purchased a set of style guides, written by a company called Taligent. Remember Taligent? The little company that couldn't? Their style guides and coding process was a Stalinistic nightmare. I strongly suspect that had a lot to do with their problems actually producing anything more than rhetoric.
My own experience is that most functions fall within the 50-200-line area, with considerable variation. If you do decent Doxygen commenting, the comments can be over 30 lines.
Also, performance is a huge consideration. I run a C++ shop, and we use C++ because it screams like a bat out of hell. If written properly. If written poorly, it is quite possible to write code that screams like a wounded brontosaurus. Many performance bottlenecks come from context switching, so long stack frames can be a problem. It may be necessary to write a large static function, in order to provide decent performance. I find "hard and fast" rules to be inapplicable when you are trying to squeeze performance from your code. Threading and cache optimization are changing the way we write code. In many ways, we are starting to write code that looks a lot like what I used to see when I wrote device drivers, 25 years ago.
Just my experience in this are. Take it for what it's worth.
Slashdot Mirror
What's really upsetting about SOPA is not the content of the legislation (there has been even nastier stuff proposed in the past, and expect worse in the future). It's the naked and unapologetic way in which the RIAA and MPAA have declared that they own the US House of Representatives. It's not new that our politicians are corrupt, spineless and clueless (indeed, the US is actually far less corrupt than most nations), but the corruption that we do have can cause so much damage. Even China can't slam the world as hard as the US, in this arena (that may eventually change).
Frankly, it's embarrassing as hell.
Sadly, I doubt there's evidence that can be used to actually convict them.
However, the story is an object lesson on the dangers inherent in modern social networks.
If THESE folks can get found out (note that some of them were actually "ratted out" by their own Significant Others), then the normal mensch on FaceBook is pretty much screwed.
Damn. I need to learn more about /. formatting. Sorry about the "wall of text."
Good points. As a manager of a C++ shop, and as a person that writes A LOT of Web and iOS stuff, I have quite a bit at stake here. My team (the job that pays my salary) doesn't do enough documentation. That's not their fault, that's mine. I haven't put enough priority on docs, and I haven't given documenting the schedule padding it deserves. That being said, I need to come up with creative ways to encourage documentation. Good process helps. A set of rules, heuristics and templates, spelling out decent coding, is helpful. It is, indeed, possible to write "self-documenting" code, but most folks won't do it, and that fox may not be worth the chase. The "sweet spot" seems to be a combination of decent coding practices, consistent style, and small, concise comments, sprinkled throughout the code. Another way is Doxygen. It works marvelously well, and I use it to create the API docs for my Web and iOS stuff (the stuff that doesn't pay my salary). As my Web stuff is public domain and open-source, it needs documentation, quite badly. I have used Doxygen to produce some truly extensive stuff. However, Doxygen produces only technical/detailed docs. We still need the "big picture" documentation and the structural stuff. That needs to be written separately. By a good tech writer. Many engineers are terrible (I mean God-awful) tech writers. In many cases (including docs that I have written), the documentation is actually WORSE than no documentation. I have written a huge amount of documentation that no one reads, because my information architecture sucks, and because I am the epitome of "prolix." I am in the process of re-evaluating a lot of my documentation, and seeing if I can get other folks, better at writing, to help out. 20 line functions? Sure, I'm sure that exists...somewhere. I've been writing code for about 30 years, in dozens of languages from hex machine code to PHP (with the lions' share being C++), and I've yet to see anything outside of an academic context follow rules like that. I once purchased a set of style guides, written by a company called Taligent. Remember Taligent? The little company that couldn't? Their style guides and coding process was a Stalinistic nightmare. I strongly suspect that had a lot to do with their problems actually producing anything more than rhetoric. My own experience is that most functions fall within the 50-200-line area, with considerable variation. If you do decent Doxygen commenting, the comments can be over 30 lines. Also, performance is a huge consideration. I run a C++ shop, and we use C++ because it screams like a bat out of hell. If written properly. If written poorly, it is quite possible to write code that screams like a wounded brontosaurus. Many performance bottlenecks come from context switching, so long stack frames can be a problem. It may be necessary to write a large static function, in order to provide decent performance. I find "hard and fast" rules to be inapplicable when you are trying to squeeze performance from your code. Threading and cache optimization are changing the way we write code. In many ways, we are starting to write code that looks a lot like what I used to see when I wrote device drivers, 25 years ago. Just my experience in this are. Take it for what it's worth.