Catch up on stories from the past week (and beyond) at the Slashdot story archive


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

Comment Re:It's pointless (Score 1) 260

I've tossed two inkjet printers into the bin for this very reason. Each time I'd printed an average of two pages before the heads were clogged or the ink had dried out. The cost of the printer is pretty much the same as the cost of a replacement set of cartridges.

Now I don't even own a printer. Literally the only things I ever need to print are ticket-less booking system receipts e.g. movie tickets, and those I just write the confirmation number onto a slip of paper.

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.

Slashdot Top Deals

A debugged program is one for which you have not yet found the conditions that make it fail. -- Jerry Ogdin