Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Ethernet (Score 2) 212

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.

Comment Re:Almost never (Score 1) 239

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) 239

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) 239

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.


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) 239

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.

Slashdot Top Deals

e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer