A programmer friend recently revealed that his company has a strict no-tabs policy, and that they are forced to use space indentation… at no fewer than eight spaces. This makes me sad.
The spaces vs tabs debate is an age-old one, with proponents on both sides fighting the cause as avidly as in the editor wars, browser wars, language wars and probably a bunch of others.
The spaces people argue that indentation should be applied by repeatedly pressing the spacebar key a certain, consistent number of times:
The tabs people, on the other hand, believe in pressing the tab key just once. This makes the next character align vertically to the next tab stop:
Personally I like to see code with its indents at 4-character widths, and when code has been indented nice and atomically with one tab per indent level, I can configure my editor to make that happen. When I make changes to the code and save it, the tabs are still there in place so the next reader could view it with tabs at 8-character widths.
With spaces, if I wanted to see a different amount of indentation I'd have to go through every line and add/remove spaces as required, and then that change would affect all other viewers of the code. It would also involve pointless updates to a version control repository.
Which do you use? If tabs, how far apart are your tab stops when you code? (For indentation, that is, which is the only time you should use them.) If spaces, can you explain the benefit to me? Please?
Update: Setting your client to insert multiple space characters when you hit the 'tab' key does not count. It's just a keyboard shortcut; you're still inserting space characters into your code that render a fixed, hard-coded amount of spacing.
If like me you lament the passing of the days when Facebook was just a tool used by twenty-somethings to post photos and have the odd flirty wallpost conversation with friends, you'll be at least partially as saddened as I to see it in the big news once again. And, once again, it's over "privacy".
Let me start by asserting that the word "privacy" is vastly overused these days; in fact, it's not just that news outlets and newbs have the seven letters on reflex action speed dial, but that in most cases the concept of privacy is misapplied.
I shan't delve into detail on this point, but I continue to exist in a state of bemusement that thousands of teenagers, students and greying parents are publishing in what is essentially designed to be a public and largely open medium… then turning around and accusing that medium of somehow breaking the rules. In fact, I suspect it's more often the case that by the time it's clear that you've published that drunk status message directly to your boss, colleagues, grandmother and ex-girlfriend, it's too late to realise that social networking is not about private communication but about public broadcast. You wouldn't project images of your face onto every building in Lenton, then complain that people had looked at them; "privacy" has very little to do with it.
Anyway, the news is that Mark Zuckerberg — the software developer who took a great product, capitalised on luck and market demand, and then turned the product into a steaming pile of rotting vegetables — has promised to revamp Facebook's privacy settings amidst complaints that they have become "too complex" for users.
But for every change mentioned — the settings grids, the blanket application controls, the new defaults — there's a paragraph about how Facebook "may not have gone far enough". How much further can you go? And in which direction? If you add more controls, then you've broken the idea of reducing the issue's complexity; if you remove controls, you run the risk of giving users far less control.
In fact, there is nothing wrong with Facebook's existing configurability (and it's good to read that those existing controls will still be available in some form). The real problem is that the untrained don't actually use the controls, because they can't be bothered to learn how to use them. As said Simon Davies, the director of Privacy International, "the vast majority of people don't use privacy settings so the reforms are not likely to have as great an impact". It's far easier to expect Facebook to automatically determine, by reading your mind, exactly who should see what whilst you continue to voluntarily and openly reveal your most intimate daily secrets to the world.
What I really want to see is less complaining about the options on the privacy settings page and blaming Facebook for drunken messages distributed over the internet, and more personal responsibility. Internet applications, like most human inventions, are complicated tools the use of which must be learned. Unfortunately, society as a whole currently seems sadly ignorant to this idea, instead reliant on blaming service and infrastructure providers for not making things simple, complex, lightweight, comprehensive, automatic and fully configurable all at the same time.
The article I've linked to ends with the very helpful, well-reasoned and informative paragraph:
The European Commission described the changes as "unacceptable".
Excellent; thanks for that.
Bootnote
Zuckerberg's claim that "we don't sell your information and we have no plans to," while intended to allay fears that specific personal information may be clandestinely and explicitly sold for profit, is ironic given that Facebook makes its operational revenue from advertising on a site that actually exists based on the provision of information. In a sense, selling information is the company's entire business model.
Apparently Mark told BBC News that it was a "misconception" that the site relies on people sharing information to make money from adverts, but anyone who's used Facebook knows that the ads are tailored to what's on your profile… especially if your profile's just been banterously 'hacked' by mates who've changed all your listed interests to choices considerably less savoury than what they were originally.
Hi. I'm here to address the age-old debate of C and C++; which pointer declaration syntax to use?
All three are equivalent because arbitrary spacing is meaningless in C/C++.
The problem with C and C++ is that its built-in operators have multiple meanings. In particular * means "pointer type", "multiplication" and "dereference". My goal when picking a convention is to, as much as possible, avoid using one that jars with another.
Therefore, we'll ignore syntax 2 because it looks so much like multiplication.
Unfortunately, there is no clear winner between the other two as each has at least one hindrance. Syntax 1 has the following:
In the code above, ptr1 is a Foo*, but ptr2 is only a Foo. One might have expected both to be Foo*s. Syntax 3 avoids this by keeping the asterisk with the name:
This is really a throwback to C's desire to have you think in terms of "I am declaring a Foo to which ptr points".
Unfortunately, this is misleading to language newcomers because in fact you're not declaring or defining a Foo at all. You're merely declaring a pointer; you still haven't allocated any actual Foo for it to point to.
A newbie reading "int *a" might think he's created an int and now gets to use "the variable *a" to access it, when in fact this is not the case at all; dereferencing such an undirected pointer would be very dangerous.
Further, aligning the asterisk with the variable name looks like a dereference operation. One of the biggest stumbling blocks to language newcomers is the multiple meaning of operators such as * and & — learning the difference between * on the LHS as a pointer type indicator and * on the RHS as a dereference operator is not aided if you see code that always aligns the asterisk in the same way.
Additionally, the name of the type itself is "Foo*" (though array declaration and function type declaration syntax oddities do make this slightly more complicated in practice).
To summarise:
| Rationale |
#1 |
#2 |
#3 |
| Indicates the type properly |
|
|
|
| Not surprising when declaring multiple variables |
|
|
|
| Does not lie about allocation |
|
|
|
| Doesn't look like dereference |
|
|
|
| Doesn't look like multiplication |
|
|
|
In conclusion:
Foo *p is rubbish; it has three cons and two pros. Foo* p is great; it has one con and four pros… important pros.
Thanks for reading.
Updated 31/07/2010: Improved table layout for clarity.
