Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment Re:COBOL (Score 1) 157

Yes, an overarching narrative is very important. If you're using something like Javadoc or Doxygen, the documentation comments are a fair place for it, but what's often even better is to put it in a design doc, which should be linked from or stored with the code. Design documents also get outdated and become wrong if not maintained, but they should be at a sufficiently high level that this happens very slowly.

Comment Re:congrats guys and gals (Score 1) 293

AFAICT, that's all about telcos. None of it implicates the companies involved in this effort. The closest is that Snowden reports the NSA compensated some companies for money they spent supporting changes to the PRISM system, but that was just a one-time offsetting of expenses, not providing a profitable revenue stream.

I still don't see any support for your claim. Is there something specific you can reference which provides a more solid basis for it?

Comment Re:what bullshit! (Score 1) 293

why, in heaven's name, would ANYONE believe this nonsense after all the lying that these corps. and agencies have been stuffing up our butts?

We have clear evidence that the NSA lied, but AFAICT none that any of the corporations involved in this effort have lied. In fact, it appears that not even the telcos -- who have admitted to handing over huge quantities of data without any legal obligation to do so -- have lied. The telcos did keep quiet until they were outed, but then immediately admitted it once the knowledge was public.

So, to what lies are you referring?

Comment Re:COBOL (Score 1) 157

What would your programming language look like if the Pointy-Haired Boss had to be able to understand it?

Lots of comments, very little actual code.

When I was in school, we had to have over 50% comments or the TA wouldn't even try to grade your program. The habit was a good one, and although I don't always get to the 50% I still put a lot of comments in my code.

That's a very bad habit, and one that you should break. Comments are evil. They are occasionally -- very occasionally -- a necessary evil, but still evil. I'll explain below.

Come to think of it, making your code understandable by the PHB is not a bad goal. If the PHB can understand what you are doing, the next poor programmer (which might be you a few months after you have forgotten the project) will have an easier job fixing something.

Absolutely, you want your code to be extremely easy to understand. In fact, that's the #1 goal, even ahead of doing the correct thing, because bugs are more likely to get fixed than unreadability, and in the long run they cost less. Comments are one way of achieving readability, but they're a crutch. Worse, they're a crutch with a built-in time bomb.

The problem with comments is that they're wrong, and they mislead the next poor programmer.

They're usually approximately correct (though rarely exactly correct) when written, but they tend inevitably towards inaccuracy as time goes on, because the code will eventually get changed, while the comments may or may not get updated to stay current. If maintainers assiduously update the relevant comments every time they change the code, then the comments stay (approximately) correct, but at the expense of requiring that additional effort by the maintainers. If someone doesn't bother to update the comments, it gets bad.

On the other hand, code that is readable without comments doesn't increase the maintenance burden and has the fantastically valuable characteristic of always being correct. Comments can be wrong about what the code does, but the code is never wrong. It may not do what is desired, but what it says is what it does (barring compiler and hardware bugs, but that's a separate problem).

I should clarify here that I'm talking about comments intended for maintainers. I have no issue with Doxygen/Javadoc/etc. comments that are used to generate documentation. They're just as error-prone, but they provide enough additional value -- in the form of the generated documentation -- that they're worth the risk and the cost. They're written, not for future readers of the code, but for future programmers who may be able to avoid reading the code.

Comments that are written for future readers of the code, however, are a code smell. They're not absolutely bad, but any time I see a comment embedded in code, it's an indicator that there's a good chance the author should have put some more time in, finding ways to make the code readable without the comment. Actually, I tend to write lots and lots of comments in my code while I'm building it, outlining the functionality I'm going to write before I write it, explaining why it's there and what it's goal is. But as I implement it, I read each section of code to decide if it's sufficiently clear that I can remove the comment. If not, I refactor until it is. In very rare cases I find that there is simply no way to make it clear without a comment, generally because there are very subtle constraints on the code which cannot be expressed in the code. Those cases are rare.

Often it's just a matter of taking a block of code with an explanatory comment at the top and factoring it out into a subroutine, with a well-chosen name that expresses what the comment used to say. If you find there's no such name that isn't a dozen words long, you need to go farther and restructure. In many cases you can eliminate comments just by adding some variables in which to place intermediate results of a calculation -- variables with well-chosen names that express what the business meaning of that intermediate result is, generally including its units, except where they're obvious (which is less often than you might think). Function/method names, variable names, class names, etc. are how you can make the meaning and purpose of your code clear without requiring comments.

I strongly encourage you to give this a try. Begin looking at the comments in your code as a bad thing, and look for ways to refactor the code so that it's just as clear (or clearer!) without the comments as it was with them. It made my code better (I used to be a heavy commenter), and I guarantee it'll improve yours as well.

Comment Re:COBOL (Score 1) 157

Anyone who has actually been suffered to write business applications in FORTRAN IV* would rather be disemboweled by a pack of rabid were-weasels than have to do that again and COBOL would appear to be a gift from Heaven.

Ah, but a Real FORTRAN programmer can write FORTRAN in any language. You ain't see nothing until you've seen a payroll system written in FORTRAN... using COBOL.

Comment Re:Tea Party welcomes LEGAL immigrants (Score 0) 220

See, still putting the cart before the horse.

Also, your characterization of illegal immigrants as criminals is factually incorrect in most cases. It isn't a crime to enter the United States without permission (there is one illegal immigration-related criminal statute, but it doesn't apply to the vast majority of illegal immigrants).

Slashdot Top Deals

It isn't easy being the parent of a six-year-old. However, it's a pretty small price to pay for having somebody around the house who understands computers.

Working...