What are the worst programming habits?

Lost User

OriginalGriff wrote:

I do #2

:laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :-O Oh I really should grow up!

PooperPig - Coming Soon

Lost User

HomerTheGreat wrote:

I assume the next developer will be at least as smart as me, if not much much smarter (likely)

Not so. You have business knowledge that you will have accumulated over time. You shouldn't need to comment straight forward code to tell the future devs technically what it is doing, but to explain the business reasons behind it.

PooperPig - Coming Soon

Lost User

Pete O'Hanlon wrote:

Secondly, learn how to use the power of LINQ, that Where statement is redundant so the statement can become myList.SingleOrDefault(p => p.Id == aUniqueId);

However, using Where(predicate).function rather than Function(predicate) is significantly faster. Incidentally a straight forward While loop is more efficient than either. So if efficiency is a concern (and we're not just talking close here, there's a big enough difference that it counts!) you need to be careful!

var found = collectionClass.FirstOrDefault(i => i.Field == searchValue);

or
2.
var found = collectionClass.Where(i => i.Field == searchValue).FirstOrDefault();

or
3.
foreach(item in collectionClass)
{
if (item.Field = searchValue)
{
found = item;
break;
}
}

The results for 100,000 collection with 100,000 searches? 1. 'normal' 78.5 1. parallel 32.2 2. 'normal' 51.2 2. parallel 31.9 3. 29.9

PooperPig - Coming Soon

Lost User

As part of No. 4 in your strangely numbered list (starting at 1!) 4a) Putting anything but the bare minimum in Setters/Getters - part of the project I am working on lives in permanent side-effect hell because some getters access the database to get values (and don't cache them) and some setters access otehr properties that access properties that access properties - and all of them have side effects 0. Method Names that don't match their function, or do more than their function e.g.

bool IsValid(Entity myEntity)
{
if (myEntity.Property = null) return false;

myEntity.OtherProperty = SomeValue;
DbService.Save(myEntity);

OtherEntity= DbService.GetOtherEntity(myEntity.Property);

return true;

}

n.) Double-Negatives

if (!notSaved || !isInvalid)

n+1.) Any code that doesn't look like it would if I wrote it on a good day.

PooperPig - Coming Soon

Roger Wright

Well, he tried, as you say. I used to program automated test equipment for missile guidance systems, and each test station had to be initiated with a local gravity vector for its physical location. Some programmers simply hard-coded a three-valued constant into the code; DATA 0.00340120, 0.00002101, 32.16254301, or some such. Moving the machine to a new location meant recoding gravity at that point, but nothing in the code told what numbers were gravity. That's just one example, and there were many much worse.

Will Rogers never met me.

Lost User

Reminded me of a story I heard about a dev who had written guidance software for tank aiming - the idea being the operator could identify a target and the software would move the barrel to track the object and fire when aimed. The story goes that the first time it was tried out on a real tank, the tank fired almost immediately - in entirely the wrong direction. Turned out that the software was full of literal values, and had been fudged during testing so the devs didn't have to wait while a virtual barrel turned laboriously around - and they'd missed a value when they took out the changes in the real McCoy! Not sure I believe it (as surely there'd need to be some feedback from the tank) but nice image of lots of brass and boffins ducking for cover!

PooperPig - Coming Soon

Brisingr Aerowing

OriginalGriff wrote:

Leaving control names at the VS default

I do that sometimes, mostly with container controls I don't reference in the code. I often get weird build errors if I set the 'Create a variable' option (or whatever that option is called, no VS instance open right now to check) to false, so I don't usually do that. I have no idea why, and it only happens with certain types of controls (e.g. Panel, Table Layout Panel, etc.) VS is weird sometimes.

What do you get when you cross a joke with a rhetorical question?

Jorgen Andersson

How about the SingleOrDefault on the same machine?

Wrong is evil and must be defeated. - Jeff Ello[^]

pkfox

That's a worry considering what those systems did ;-)

We can’t stop here, this is bat country - Hunter S Thompson RIP

pkfox

"this" was introduced for a reason and should be used.

We can’t stop here, this is bat country - Hunter S Thompson RIP

Roger Wright

I don't have any trouble believing that story, as I've been part of worse. Back in the days when the Phalanx gun system was being developed by my company, at a demonstration session they fired it up in front of a bunch on Navy brass (unloaded, but still noisy as hell), it deployed from its clamshell mount, spun around and locked on the first available target - the bridge of the ship where all the brass stood watching. I suspect a lot of dress whites needed cleaning that afternoon, and I dearly wish I could have been there to see it. Happily, I was still in school when I started working at General Dynamics, and my Control Systems instructor was a part timer whose day job was chief engineer for Phalanx at General Dynamics. He was there, and told us all about it. Then he assigned us a 10 question take home, open book exam that contained all the field measurements, design equations for the control loop, and target classification algorithms, and required us to solve the problem and properly assign constraints and design compensation circuits to stabilize the control system. Apparently we managed to solve the problem for him, as the error never happened again, and I passed the class. That was the single, most difficult test I ever took, as it was all using real world data - not theoretical nonsense that textbooks present - and each question depended upon the answer to the one before it being correct - exactly how the real world works for an engineer. If you get step two wrong, in the real universe, everything that follows will also be wrong, though you might not notice that until step 28, years and million$ later. :-O

Will Rogers never met me.

Charl

Team work often brings out the best (and the worst) in people. My peeves are about devs who indulge in: 1. Sending an email to the dev in the next cubicle instead of simply having a chat 2. Refusing to commit code until it is "perfect" 3. Making working code not work in the name of "refactoring" 4. Spending a week perfecting the latest LINQ statement and being unable to debug or optimise the thing 5. Deciding mid-project to change data access 6. Bitching about FXCop 7. Logging? What logging? 8. Hubris 9. Read the spec - real devs don't read specs! My two fav's are: Inline braces and swallowing exceptions

Plamen Dragiyski

Since I use javascript I'm guilty about 2), but here it is: 6) use of lambda functions inside lambda functions (even inside lambda functions). 7) inline conditions, functions and constructing objects:

var i, o;
for(i = 0; (function() { ... })(); ++i) {
o = new (objlist[i])();
}

Although I never allowed 3). If a tool cannot properly autoformat my code, according to my standards, then that tool is thrown away.

Stefan_Lang

That's got nothing to do with self-commenting code, it's just that the comments are pointless - which is yet another bad programming habit:

n+1. comments that state the obvious

In your example, comments could still be useful if they pointed out e. g. what is expected of the user object to be considered valid, what is expected of the user to fix the problem, or if the user not being valid may be an indication of an internal error, because the user object is expected to be in a valid state upon calling this function.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Stefan_Lang

Could have been worse, like

const int FiveHundred= 450;

;P

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Stefan_Lang

Forogar wrote:

Which one to delete when refactoring?

Both. :cool:

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Stefan_Lang

Jacquers wrote:

university [...] didn't teach him good coding standards

Coding standards? At university? :omg:

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

R Erasmus

Checking code into source control that doesn't compile.

"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>

R Erasmus

Neglecting the design phase: - reverse engineering the design requirements because the design was neglected.

"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>

Martin Hart Turner

;) 3) This can be a project killer, good observation. 4) There is no excuse nowadays, there are plenty of tools available to help with refactoring. 5) :mad: 6.1) Unforgivable! Good observations!