Simply not using Google products won't protect you from this as it is using scripts embedded in web pages. Google analytics Gstatic and Googleadservices just to name a few
Google provides tools to opt out of Analytics and Ads tracking, which will suppress these cookies.
Most of my comments are Doxygen, at least from a line count perspective. I try to document every method's inputs, returns and what it reads and modifies and what it is attempting to do.
This part is good. Documenting every identifier is generally not a good idea; instead put the effort into naming identifiers so they're self-documenting. Same with documenting every logical edge; put the effort into making the code itself explain the intent and rationale.
Sure, you have to *maintain* comments along with the code, but the time you save when you have to pick up some code to maintain it later is going to make it worth it in most cases.
Only if you ignore the time it will cost you when the comments are wrong, which tends to be orders of magnitude higher.
So, I don't agree that "comments bad" they are not. In my experience, they are not used enough.
I used to feel the same way, then I acquired more experience, on larger codebases.
For a more complete explanation of why comments are bad, I recommend Martin Fowler's book "Refactoring: Improving the Design of Existing Code". There are a few other books that cover it as well, but I think Martin's chapter on the topic explains it concisely and effectively.
So instead of having a block of code with an explanatory comment at the top which can not possibly serve a generic purpose, you want people to refactor it into one or more functions, each with their own explanatory comment at the top for generating documentation
No, these subroutines aren't part of the public interface, and not only don't need documentation comments, but shouldn't have them.
even though they have hardcoded values inside which prevent their use anywhere other than where the original code was
Uh, that's another problem. You should always at least extract those to constants.
I guess you haven't actually worked on code professionally in a while
LOL. Well, I've only written a little code today because most of it has been spent in meetings. Tomorrow will be more productive, though.
Sounds like 3x the work for 0.25x the functionality, with an overall increase in entropy.
As such they are likely to have a sense of morality, as we do, and to be interested in the welfare of other creatures, as we are.
So they would follow the Prime Directive and avoid letting us know about them, except when a randy captain decides to come and have sex with our women.
If I remember correctly, the predominance of humanoid species in Star Trek was due to the low number of non-humanoid actors in the Screen Actors Guild.
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.
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?
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.
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 res
Hmm. I always thought assembly language was the input and the assembler was the tool. However, I turned to Wikipedia for support and found that usage is inconsistent.
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.
I didn't know a soul at my current employer when I got the job. Nor at the last employer. Come to think of it, I haven't known anyone at any of my employers until after I started working there.
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).
In fact, those companies KNEW about the spying (they were asked by the gov, many many times, to reveal info about their users)
Your parenthetical is presented as support for your assertion, but it isn't. The fact that they were asked many times, whether via lawful orders or otherwise, indicates nothing about whether or not they knew of secret data gathering by the NSA. They've claimed in public statements that they didn't know about it. Most have also claimed that they didn't comply with any requests except where they were obligated by law. I see no evidence to refute either claim. Do you? If so, can you point it out?
If the issue is illegal vs legal, give the illegal immigrants work visas, making them legal. Problem solved, right?
You seem to think there's some bright line here, when there really isn't. The vast majority of illegal immigrants would love to come legally, and are here to work and to contribute, but we won't let them. It's insanely difficult to immigrate legally except as a wealthy student or with corporate sponsorship. Outside of those categories it is -- quite literally -- a game of chance, a system of tiny quotas allocated by big lotteries.
It's criminal how you and others cannot seem to distinguish between legal and illegal immigration, which are vastly different things.
That distinction is based on the lines drawn by our immigration laws, which are very arbitrary and capricious, in both design and implementation. I find it really interesting how none of the people who rail against illegal immigration actually know (or care!) how legal immigration works and whether or not the rules are in any way effective at dividing those we'd like to have from those we wouldn't.
Put the cart in front of the horse: reform immigration laws so immigration is possible for those who just want to come and work, then enable all of the current illegal immigrants to make use of the revised laws to obtain legal status and then we can figure out how to secure the borders. At that point it will be much easier because there will be many fewer people anxious to sneak in.
If you think that you are immune because you are "a professional", just wait. Get 10 or 15 years of experience and watch that become the reason that you won't be hired.
Hmm. I have 26 years of experience. How much longer do I need to wait? I work with a couple of guys who've been professional programmers for nearly 40 years. The industry had better hurry up and ruin them pretty quickly, or they'll retire first.
Literally, neighbors are asking people, 'Why are you spying on Grandma?'
So, they're hoping that the public approval of the president will keep them from having to come up with an answer to that question?
The answer to that question is obvious. Here's what they say "We aren't spying on Grandma. Sure, we're gathering up her information along with all the rest, but we don't actually look at it, or use it. And we can't be selective about what we grab, because then we'd sometimes miss stuff that's important. So need to continue grabbing everything, just in case, but, really we're nice people and we would only use it to help the American people. Okay, so there's the occasional bad apple who abuses it (e.g. LOVEINT), but we try to find them and get rid of them."
Does getting that answer make you feel any better about it? Probably not. It doesn't make me feel any better, even though I can see clear as day how a bunch of well-intentioned, hard-working people could follow this particular road right into massive surveillance hell, fully convinced that they're doing the right thing. From their perspective, it's easy to see that they are only doing good things, if we'd only just trust them. From our perspective, we can't know what they are or are not doing, and they're doing it without our permission and in contravention of our most fundamental law, no matter how they try to split hairs.
Slashdot Mirror
Alternatively, the Google-provided Keep My Opt-outs plugin will prevent Google from ever sending you the PREF cookie.
Simply not using Google products won't protect you from this as it is using scripts embedded in web pages. Google analytics Gstatic and Googleadservices just to name a few
Google provides tools to opt out of Analytics and Ads tracking, which will suppress these cookies.
See http://google.com/privacy/tools, the bottom two entries.
Most of my comments are Doxygen, at least from a line count perspective. I try to document every method's inputs, returns and what it reads and modifies and what it is attempting to do.
This part is good. Documenting every identifier is generally not a good idea; instead put the effort into naming identifiers so they're self-documenting. Same with documenting every logical edge; put the effort into making the code itself explain the intent and rationale.
Sure, you have to *maintain* comments along with the code, but the time you save when you have to pick up some code to maintain it later is going to make it worth it in most cases.
Only if you ignore the time it will cost you when the comments are wrong, which tends to be orders of magnitude higher.
So, I don't agree that "comments bad" they are not. In my experience, they are not used enough.
I used to feel the same way, then I acquired more experience, on larger codebases.
For a more complete explanation of why comments are bad, I recommend Martin Fowler's book "Refactoring: Improving the Design of Existing Code". There are a few other books that cover it as well, but I think Martin's chapter on the topic explains it concisely and effectively.
So instead of having a block of code with an explanatory comment at the top which can not possibly serve a generic purpose, you want people to refactor it into one or more functions, each with their own explanatory comment at the top for generating documentation
No, these subroutines aren't part of the public interface, and not only don't need documentation comments, but shouldn't have them.
even though they have hardcoded values inside which prevent their use anywhere other than where the original code was
Uh, that's another problem. You should always at least extract those to constants.
I guess you haven't actually worked on code professionally in a while
LOL. Well, I've only written a little code today because most of it has been spent in meetings. Tomorrow will be more productive, though.
Sounds like 3x the work for 0.25x the functionality, with an overall increase in entropy.
Nonsense.
As such they are likely to have a sense of morality, as we do, and to be interested in the welfare of other creatures, as we are.
So they would follow the Prime Directive and avoid letting us know about them, except when a randy captain decides to come and have sex with our women.
If I remember correctly, the predominance of humanoid species in Star Trek was due to the low number of non-humanoid actors in the Screen Actors Guild.
Damned unions.
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.
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?
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?
The NSA does buy it from them.
Cite?
Pick one. Start with Google, if you like.
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 res
Hmm. I always thought assembly language was the input and the assembler was the tool. However, I turned to Wikipedia for support and found that usage is inconsistent.
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.
You're a fuckwit.
Irony so thick you can cut it with a knife.
Everyone I know who's good at what he or she does has a job.
+1
Congrats, you won the friend lottery.
I didn't know a soul at my current employer when I got the job. Nor at the last employer. Come to think of it, I haven't known anyone at any of my employers until after I started working there.
There is a saying: "the road to hell is paved with good intentions..."
I think it applies here all too well.
Did you not notice my reference to a "road right into massive surveillance hell"?
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).
In fact, those companies KNEW about the spying (they were asked by the gov, many many times, to reveal info about their users)
Your parenthetical is presented as support for your assertion, but it isn't. The fact that they were asked many times, whether via lawful orders or otherwise, indicates nothing about whether or not they knew of secret data gathering by the NSA. They've claimed in public statements that they didn't know about it. Most have also claimed that they didn't comply with any requests except where they were obligated by law. I see no evidence to refute either claim. Do you? If so, can you point it out?
More importantly, this same corporations are the contractors that facilitated these acts.
Cite?
these 5, in particular, have shown a history of not minding deceitful marketing in the slightest
Cite?
If the issue is illegal vs legal, give the illegal immigrants work visas, making them legal. Problem solved, right?
You seem to think there's some bright line here, when there really isn't. The vast majority of illegal immigrants would love to come legally, and are here to work and to contribute, but we won't let them. It's insanely difficult to immigrate legally except as a wealthy student or with corporate sponsorship. Outside of those categories it is -- quite literally -- a game of chance, a system of tiny quotas allocated by big lotteries.
It's criminal how you and others cannot seem to distinguish between legal and illegal immigration, which are vastly different things.
That distinction is based on the lines drawn by our immigration laws, which are very arbitrary and capricious, in both design and implementation. I find it really interesting how none of the people who rail against illegal immigration actually know (or care!) how legal immigration works and whether or not the rules are in any way effective at dividing those we'd like to have from those we wouldn't.
Put the cart in front of the horse: reform immigration laws so immigration is possible for those who just want to come and work, then enable all of the current illegal immigrants to make use of the revised laws to obtain legal status and then we can figure out how to secure the borders. At that point it will be much easier because there will be many fewer people anxious to sneak in.
If you think that you are immune because you are "a professional", just wait. Get 10 or 15 years of experience and watch that become the reason that you won't be hired.
Hmm. I have 26 years of experience. How much longer do I need to wait? I work with a couple of guys who've been professional programmers for nearly 40 years. The industry had better hurry up and ruin them pretty quickly, or they'll retire first.
Literally, neighbors are asking people, 'Why are you spying on Grandma?'
So, they're hoping that the public approval of the president will keep them from having to come up with an answer to that question?
The answer to that question is obvious. Here's what they say "We aren't spying on Grandma. Sure, we're gathering up her information along with all the rest, but we don't actually look at it, or use it. And we can't be selective about what we grab, because then we'd sometimes miss stuff that's important. So need to continue grabbing everything, just in case, but, really we're nice people and we would only use it to help the American people. Okay, so there's the occasional bad apple who abuses it (e.g. LOVEINT), but we try to find them and get rid of them."
Does getting that answer make you feel any better about it? Probably not. It doesn't make me feel any better, even though I can see clear as day how a bunch of well-intentioned, hard-working people could follow this particular road right into massive surveillance hell, fully convinced that they're doing the right thing. From their perspective, it's easy to see that they are only doing good things, if we'd only just trust them. From our perspective, we can't know what they are or are not doing, and they're doing it without our permission and in contravention of our most fundamental law, no matter how they try to split hairs.