I had half a dozen email addresses @eircom.net, which used to be an ISP in Ireland, but the current owner (now called Eir.ie) decided to start charging 6 euro a month per email address. Not going to spend over 200 quid for just the email, so I registered a domain -- I'm currently using www.spiralhosting.com for hosting (with their cheapest hosting plan because I only wanted some email) and it's working well, 49 euro for as many email accounts as I want. I did register the domain with a different organisation but I gather you already have that.

RossMW wrote:

Do you have any tips on keeping these damn { } under control?

Always, always, always have my opening and closing brackets in the same row or column. And put comments after }, as Member 10707677said. Trying to figure out where the missing { is when people put the opening { on the same line as the function or if, is just making life unnecessarily hard. And sometimes I come across conditions that are so ugly, I have to do it there too...

if (((x==0) && (y==1)) && (z==2) && ((w==3) && foo==bar))

if ( ((x==0) && (y==1))
&& (z==2)
&& ((w==3) && foo==bar)
)

Occasionally, I have to go and ask whoever wrote it... why?

"if you used some kind of definitions for boolean values, you had to 'translate' your results in similar ways as shown here." Not true! In C[1], the expression is false if it's 0, true otherwise. You NEVER compare to a specific non-false value. You can use a definition for a non-false value, as a "sample" true to return from functions or to set variables, but it is very bad practise to compare anything to that value. This construct may be harmless enough in C#, but a C programmer who used this construct should be larted. Hard. Otherwise he'll start comparing things to whatever value the identifier "true" value, and end up with bugs because in C "true" is just not unique! [1] I don't use C++, but it does have a boolean datatype

it's obvious why. The braces are used to mark the start and end of a block, and you have them here in the same column (so your eye knows where to go to look for it) and without hiding them in other text. This is obviously a good style for this language. If you, or the person who taught you, or (the person who taught)^n you comes from a language where keywords delimit blocks, then you could end up with the style where braces are placed on the same line as the keyword. So if (a>b) ... blah ... else ... blah ... endif becomes if (a>b) { ... blah ... } else { ... blah ... } This is clearly inappropriate behaviour in the latter case because the keywords here do not delimit the block. The braces do, but they are made more difficult to find. It is appropriate in the other language, because the keywords which delimit the block are in the same column and are not hidden in other text.

Because tabs predate high-level programming languages. On a typewriter, you can set the tabs to get text to line up, BUT the big thing about them is that a tab could be one level on one page, another level when you go to type in a different column of names, or whatever. And when you go to type the next document, you could set different tab sizes. Go to a different typewriter - you are certainly not continuing the same document, so you will have different tab settings again. Look at tabs in a word processor - that's the sort of thing they are for. In a programming language, you want your levels of code to be indented by a certain amount, which you do not want to change half way down the file, or when you go to a different PC. And tabs are just the wrong tool for that. Spaces (in a monospaced font, and that's the only type to use when programming) have the same width as any other character. Always. And that's what you want when indenting. The tab key should indent by the amount you want, and the backspace (or typing a } ) should outdent you by the same amount. But that's interpreted by the editor, not by whatever is converting your source code into a displayable format -- which might be an editor, or it might be someone else's editor, or maybe a printer if you're being retro. So the editor should do what the keys you press tell it to do, and record the result unambiguously in your source code file. And "unambiguously" means with spaces. Recording a tab character in the source code means that what you type will be reinterpreted by the editor that is loading it, and the way it is reinterpreted may not be what you intended.

Spaces always. Tabs are 8 chars, or 4 chars, or 3 chars, or something else depending on the phase of the moon. They are *meant* to be configurable, and your indentation is probably not. Just because some printers in the 1980s had fixed tab width doesn't mean you can rely on it. And if you are working with a variety of people and/or tools, sooner or later you'll get your code back with the wrong tab size and give yourself pain. Use spaces and then everyone knows where you're indented.

Pravarakhya wrote:

ginger (exception)

No -- both instances of g in that word are pronounced as in gin. There has been a move to mispronounce both gs in that word, in order to deprecate red-headed people. But it's wrong, and unfair, especially given how good-looking red-headed people can be.