Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:Almost never (Score 1) 228

Code for what might happen, not what your ego tells you you will get away with.

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.

Comment Re:Never - But Because Your Definition of Unnecess (Score 1) 228

Occasionally I include solutions for problems which have not yet been uncovered. Those methods may not be called (dead code) and any kind of static analysis would report them as "unnecessary." If I make the decision that such code will help me, or help someone else, later then I believe it is totally necessary, and good to include. Worse-case is that it will be a good starting point for someone later, and they will throw it away and replace it with something better.

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.

Never include unnecessary code

See above.

I constantly include semicolons, and brackets around one-line conditionals - those are defensive practices which are designed to prevent future problems, and aid in clarity.

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.

Comment Re:View from on high (Score 1) 228

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.

Comment Re: View from on high (Score 1) 228

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.

Comment Re:Almost never (Score 2) 228

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.

Comment Re:Anything for work (Score 1) 228

I'm not a fan of assigning a variable inside an if statement. It's harder to read than several short, clear lines, and it likely compiles to the same assembly in the end.

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

Comment Re:Anything for work (Score 1) 228

I write game code in c++, so the expectation is anyone coming to work on the code has a pretty decent level of skill in c++. I early out whenever it makes sense, but obey the "one return" rule is there is nothing to gain from short-cutting the evaluation path. Game coders are used to multiple returns, so it's not a big deal for them.

Comment Re:Anything for work (Score 1) 228

+1 for the 'why' remark.... ...i'd also add, that it should explain semantics when needed, out of bounds logic, reasoning where it isn't obvious, and addendums to what the code is doing.

I'm a firm believer that you should be able to page through code reading only the "green code" in order to understand what is happening.

Where code perfectly expresses the algorithm / concept, few comments are needed...but the rest of the code should be commented to hell.

Comment Re:Ahem (Score 1) 348

"I''ve heard on various occasions that even people forced to use windows for a text writing job are more productive when using their own favourite editor, like vi, then importing the result into the fancy wysiwyg thing supposed to be used, and finishing up with some formatting work. You too could install a fave text editor and use that. What's stopping you?"

The 80s were over 30-35 years ago.

Slashdot Top Deals

"Catch a wave and you're sitting on top of the world." - The Beach Boys

Working...