Is that you, Accenture?

It took about 4 minutes of my time and I never heard from them ever again. Time well spent I'd say. YMMV.

I didn't pay for a licence for probably 5 years, telling them I had cut the cable and removed the antenna. The worst I ever got was a letter every year or so and one visit from the licence people. They came up, saw I had a TV and DVD player, and left. It was exactly what I told them they'd find.

I didn't need the broadcast BBC content at that time, since there was pretty much nothing good on. DVDs and downloaded content were all I needed.

Enjoy your life in the data ghetto that is the USA. If you want to talk to anyone from the other 95.6% of the world then it's time to get that 8th grade education you should already have.

Don't worry, at 76C you will soon be dead. It won't matter what you are wearing.

Experience tells me what might happen is that code and projects are broken up based on the experience of the teams working those code bases. You don't ever let an advanced code base get taken over by an inexperienced team. You will always have an A team, a B team, and the other guys. What is right for the A team is not right for the B team or the other guys - and it goes down the line.

There is always going to be advanced projects in languages that most team members will shy away from or will be too damn hard for them to work with - that's totally fine. Your 'B' team is most likely the vast number of team members. The 'A' team are those members able to work at the highest level, whatever that is within your organisation. They will take care of the really awful projects that need kid gloves to keep working, and they will prefer doing that work - because they know that's where they are challenged.

'B' team is the bulk of most teams. Your arbitrary rules are probably quite OK for these guys. They might even be best for most of these guys. Following the rules won't really harm them, as they will create / maintain code bases that also follow those rules - that's most code. Only the 'A' team members need to worry about code that breaks these sort of rules, and...why.

If syntax is causing you issues, you are the other guys.

This is called YAGNI - You Ain't Going to Need It, and all it does is clutter code and make it harder to see what is truly needed vs what some programmer thought might be needed at some point in the future, if some things changed. Don't do it. Alternatively, place it in as scaffolding, but remove whatever elements aren't needed before you ship the code.

See above.

No decent programmer needs these, and often they just clutter the code. Only put in the semicolons and brackets that are actually needed by the language.

I agree with the final statements, though not the ideas you expressed which would be actionable items by those statements.

+1 for writing code that you need to read 10+ years later

And that is why almost every country in the world uses SI units instead of outdated imperial measurements, like the US.

Competent programmers, never. It's only for the other ones.

Current wisdom is to define variables just before, or exactly as, you use them. This benefits the compiler as well as readability and cut and paste.

e.g.

vec3 v = OtherVec * SomeQuat;

vec3 abc = v * OtherQuat;

Your IDE will let you know pretty quick if you cut and paste it wrong. The CPU will thank you for your declarations and assignments, especially if it can shortcut some of it.

I haven't printed out my code since 1988.

I understand the sentiment, but it's just really not true anymore. Even just having a CRT makes following that rule unnecessary, let along a modern LCD which can easily handle 160 x 80 lines of code. Even still, I would never arbitrarily format my code to fit the screen resolution of the device I was currently using. To paraphrase the words of Fight Club "Code will go on as long as it needs to.".

It's just not true that a programmer needs to read the whole damn function on a single page, at least...not since the invention of the Page Up and Page Down keys.

I'm working with some code (written elsewhere) which includes functions over 1000 lines long. While this is very definitely the other end of the argument, those functions are that length for a reason - they are doing something really complex that is just one function.

I'll probably refactor those all down to a few hundred lines each or fewer, when I get the chance. But I won't consider the length of my screen when I do it - rather, the natural break down points of each function. Even so, doing that will introduce something new and weird to the project. Instead of the functions being explicitly defined, and only the functions - now it will need to define all the sub-processes that are needed to make them happen. Something is lost in doing that, high level clarity.

Agreed, if one branch is more than one line - and disagree if they are both only one line, or there is only one branch.

Any c++ programmer with more than 1 years experience will see this immediately and slap some braces around it. Thanks to modern IDEs and standard indentation (which the IDE will auto-correct) it's extremely unlikely anyone will make this mistake, or it will go unseen for very long.

I'd group this sort of 'error prevention' in the same category as putting the constant first in every if statement e.g.

if (1 == YouShouldHaveDoneThisTheOtherWay)
{
        Whatever();
}

The people who make the mistakes that this shit prevents have no place working on code.

I'm guessing you mean inside the if () part of the statement rather than in the body of the statement for the if.

I'm not a big fan of it either, but I see it often enough because i work with a lot of outside code. I typically see it looking a bit like this:

if (auto x = SomeTest ())
{
}

which always make me second guess the '=' statement...should it be '=' or '=='. It's valid syntax and it's both shorter and helps to contain the variable X to within the statement enclosed in parentheses, but...it's jarring to someone who is on the lookout for misuses of the assignment and equivalence operators. That said, it's awesome, so I use it myself :D