Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›2 »

floWenoL: Oct 23, 2002

Avenging Dentist posted:

Some point along the way, retVal will become true (found a valid item), so it should stay true. Of course, a sane person would just say "if(item.isValid) return true;" but that's neither here nor there.

Also my favorite is still
code:
#define private public
#define protected public

code:

#define private public
#define protected public
#define class struct

# ¿ Mar 21, 2008 21:39

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 16:34

floWenoL: Oct 23, 2002

wwb posted:

True that. Why all the hate for "single point of return"? I don't follow it 100%, but it can definitely make sense in some scenarios.

Because it's an archaic overreaction to spaghetti code. It should be used only when doing so would make the code most clearly understandable.

# ¿ Mar 22, 2008 01:21

floWenoL: Oct 23, 2002

nebby posted:

...I still think calling a return value "ret" or "result" is the goddamn stupidest idea I saw posted in all of those trainwrecks of threads I started.

I assume you're not counting your own posts.

# ¿ Mar 29, 2008 06:35

floWenoL: Oct 23, 2002

quote:

...the context-sensitive return value of an array...

To be honest I like explicitly specifying scalar(@a) for array length as the fact that @a reduces to its length in scalar context (and length(@a) is wrong!) is loving gross.

# ¿ Mar 31, 2008 20:21

floWenoL: Oct 23, 2002

my stepdads beer posted:

Can you explain why it's stupid? Looks okay to me

What happens when s is null?

# ¿ Apr 8, 2008 07:29

floWenoL: Oct 23, 2002

FrantzX posted:

code:
public String GetProperty(String key)
{
     ValueType value;
     if(map.TryGetValue(key, out value) == true) return value.ToString();

     return null;
}
I'd do it this way for only one lookup plus it won't throw an exception is the key is not found in the dictionary.

Gotta love that "== true".

# ¿ Apr 10, 2008 22:17

floWenoL: Oct 23, 2002

crazypenguin posted:

I never understood why they chose to make ++i and i++ different functions, rather than just having a single ++ function and just change when it gets called relative to when it is evaluated.

This is C++'s idea of flexibility. :rolleye:

# ¿ May 7, 2008 10:30

floWenoL: Oct 23, 2002

Incoherence posted:

It's possible that a present-day compiler could optimize for (int i = 0; ...; i++) into ++i, but probably not any sort of class (the previously mentioned example where some rear end in a top hat defines operator++() and operator++(int) to do different things).

No, iter++ should be optimized just fine most of the time, given that iterators are usually part of templated class (and hence the function definition is visible) and operator++s are usually short enough to be inlined. A simple dataflow analysis pass should enable the compiler to conclude that the copied variable is not used and therefore can be omitted, assuming the copy constructor etc. have no side effects. Indeed, for the following code gcc 4.x (which doesn't exactly emit the fastest code) still manages to generate the same code for pre() and post() with -O2:

code:

#include <vector>

int pre(const std::vector<int> &v) {
  int x = 0;
  for (std::vector<int>::const_iterator i = v.begin();
       i != v.end();
       ++i) {
    x += *i;
  }
  return x;
}

int post(const std::vector<int> &v) {
  int x = 0;
  for (std::vector<int>::const_iterator i = v.begin();
       i != v.end();
       i++) {
    x += *i;
  }
  return x;
}

# ¿ May 7, 2008 10:42

floWenoL: Oct 23, 2002

TSDK posted:

(Emphasis mine)

That's the biggie though, and I'm not sure that's common to a lot of compilers.

Eh? By side effects I mean something like the copy constructor doing cout << "Copy constructor called!", which isn't common.

quote:

I'm willing to bet that the same code was generated on each for the vector example because the iterator is a simple typedef to a pointer. What happens with a std::list or std::map?

That's a good point, though; I had assumed vector iterators were wrappers around pointers instead of simple typedefs. I tried it with std::list and std::set, though, and the two are still identical.

# ¿ May 7, 2008 20:34

floWenoL: Oct 23, 2002

tripwire posted:

Gotos have no place in OO (or really any kind of structured) programming. Maybe you'd feel more at home with fortran?

Here's a nickel, kid, go buy yourself a C book.

Zakalwe posted:

Until you add another loop and WHOOPS, you're not where you think you should be.

Modern (non-lovely *cough*) languages like Java and Perl provide labeled loops and ways to break out of them, so that removes one of the two remaining use cases for gotos nowadays, and exceptions remove the other one.

floWenoL fucked around with this message at 04:19 on Jun 15, 2008

# ¿ Jun 15, 2008 04:15

floWenoL: Oct 23, 2002

Evis posted:

I guess I missed this aspect of C since I've almost exclusively worked in C++. http://en.wikipedia.org/wiki/Boolean_datatype has even more information on it.

C++ is not immune to this.

# ¿ Jun 21, 2008 02:21

floWenoL: Oct 23, 2002

Lexical Unit posted:

So long as you practice good const correctness, this issue should be made pretty clear from the function signature. And really, if you're using a function, I'd expect you'd be familiar with that much at the very least.

The person who wrote the code may be completely familiar with the function, but maybe not the person reading the code later.

# ¿ Sep 1, 2008 14:06

floWenoL: Oct 23, 2002

Lexical Unit posted:

So what is the person who's reading the code going to get out of reading it if they don't know what any of the functions do?

Whatever can be gleaned from the function name, comments, and parameter names. If pointers for output params were used consistently, a simple search suffices to find out where a variable can be modified in a called function. If they're not, one has to look up each function where said variable is used as a parameter. Lame.

# ¿ Sep 1, 2008 21:28

floWenoL: Oct 23, 2002

BigRedDot posted:

code:

template <typename T>
bool ScrapValueFromWidget( Widget * w 
                           T &      val ) { ... }

I don't get why you can't use T *val here.

# ¿ Sep 1, 2008 21:30

floWenoL: Oct 23, 2002

Mustach posted:

code:
f(&p, NULL, &r);
Argh my program crashed because the function tried to dereference and write to NULL. Also which of those are output params; I think this function takes at least one pointer-to-const.

I don't know if you're being intentionally obtuse, but the idea is to use pointers (and not references) only for output parameters. Not to mention that you really shouldn't be passing in NULL to a function without checking that it does handle it. Note that this is a burden only on the code writer and not the code reader.

quote:

Yeah that's real tough.

Oh, how cute, someone who has never done maintenance on a large code base.

# ¿ Sep 1, 2008 22:04

floWenoL: Oct 23, 2002

StickGuy posted:

So... you should always have to check whether functions can handle NULL pointers, but you should never have to check whether or not a pointer is being used for input or output?

Hint: one has to be done only by the code writer, and the other may potentially have to be done by code readers/maintainers.

# ¿ Sep 2, 2008 00:26

floWenoL: Oct 23, 2002

Mustach posted:

There are plenty of currently-existing functions in the world that take pointers as input parameters, and Anonymous Name already mentioned passing in NULL as a valid argument.

There are plenty of currently-existing functions in the world that take {pointers,references} as {input,output} parameters; so what? If you're in a position where you (as a company) can apply a consistent coding standard and you're working more with your own code than third party code, standardizing on pointers as output parameters is a feasible thing to do.

I don't really see what Anonymous Name said has anything to do with what I said, but whatever.

quote:

Being able to search for "&v" over "v" is not the huge timesave you're making it out to be. Java has no "const"; any method can modify any object that's passed to it if the object's class has mutators. That hasn't stopped the creation of huge and functioning Java codebases, probably because they aren't structured so that "I don't know where this variable is being modified, time to search every source file" becomes possible.

It's not going to save you gigantic amounts of time, but if you're working with a large codebase with many contributors every little bit helps. Also, there are huge and functioning {assembly,COBOL,MUMPS} codebases that do not have "const" either; I don't see what *that* has to do with this discussion, either.

# ¿ Sep 2, 2008 00:31

floWenoL: Oct 23, 2002

JoeNotCharles posted:

And yet you keep saying you the writer of functions should be checking for NULL and things like that... Why would you trust the writers of functions in a large code base? Guaranteed at least 50% of the people who worked on them are blithering idiots.

Wrong-o. I'm saying that the writer of functions should be documenting whether their functions handle NULL or not. And if the writer of the function is indeed an idiot and didn't specify the behavior, well, then you (the maintainer) can assume it doesn't; the result will be no worse than that in the reference case (since a "NULL" reference is undefined).

# ¿ Sep 2, 2008 00:53

floWenoL: Oct 23, 2002

Vanadium posted:

I am not really willing to give up the convinience of using references for "out" parameters just so you guys do not have to look up the function, sorry guys

Don't you have physics homework that needs doing, Vanadium? :v:

# ¿ Sep 2, 2008 00:55

floWenoL: Oct 23, 2002

That Turkey Story posted:

So in other words you get exactly the same behavior when using a pointer except that with a reference you know that an object must be passed based simply based on the parameter type whereas with a pointer you only know if you read further documentation.

You get behavior that is *no worse* than using a reference and potentially more readable. :P

I kind of regret bringing this up because it always turns into a shitfest. Honestly, if it's for your own personal project or whatever it doesn't really matter. Didn't we come to an agreement the last time? You mentioned some sort of syntax like "Foo(bar, out(baz))" and I think something like that would be fine if it were applied to the standard libraries (which is a pipe dream, I guess).

# ¿ Sep 2, 2008 01:02

floWenoL: Oct 23, 2002

BigRedDot posted:

There's absolutely never a case where NULL should be passed in, but allowing T * would mean the function now has to check that in every single case. That's just silly, and I don't want to do it.

No it doesn't. That's silly.

# ¿ Sep 2, 2008 01:08

floWenoL: Oct 23, 2002

Mustach posted:

If that's what you really meant, then I'm going to drop it, too. My biggest problem was with the idea that pointer-as-out was some kind of replacement for reading function documentation/asking a coworker; the rest just spun off of that and is apparently well-beaten horse.

Sure. I wasn't arguing for it to be a replacement for documentation, but simply as a way to avoid having to look up the documentation less often, given that certain conditions hold (large code base, enforceable code standards, limited interaction with third-party apps, etc.).

TTS gave a pretty good summary of the differences between his and my view point, and I agree that his position (that the "nullability" of a parameter is an important piece of information to keep) is a valid one. Honestly, the whole thing would be moot if C++ had some way to return multiple values. :v:

^{Okay let's stop derailing this thread.}

# ¿ Sep 2, 2008 03:29

floWenoL: Oct 23, 2002

Aredna posted:

INT_MAX / b = 39999.32, which will be rounded down to 39999.

Since A > 39999, it'll pass the overflow test.

So? It's still greater than the "real" answer, 39999.32, which is fine.

# ¿ Sep 2, 2008 23:55

floWenoL: Oct 23, 2002

JoeNotCharles posted:

In the case of five billion it sort of makes sense because if you're typing 5000000 over and over again it's really easy to drop a 0 accidentally.

If you were using Perl you'd be able to type 5_000_000. :colbert:

# ¿ Sep 4, 2008 19:54

floWenoL: Oct 23, 2002

JoeNotCharles posted:

The difference between an unsigned integer and a signed integer is often accidental - if you just automatically make an int, but you know it'll never get a value less than 0, you might want to change it to an unsigned int later to get more range.

No you don't.

# ¿ Oct 3, 2008 09:43

floWenoL: Oct 23, 2002

Mikey-San posted:

why

Some things are just complex and wouldn't benefit from trying to artificially split it up. That and C is pretty low-level so it can get verbose.

# ¿ Dec 22, 2008 21:18

floWenoL: Oct 23, 2002

That Turkey Story posted:

This. Take whatever floWenoL says with a grain of salt, he's not very smart and he loves to mislead people by giving purposely false information. If all of your functions aren't less than 10 lines you probably made a huge mistake/are a terrible programmer. He's also really freakin gay.

It's...true. :eng99:

Edit:
Okay, 3000 lines *is* a bit much. But splitting up functions just for the sake of bringing per-function line count to some arbitrary maximum isn't a good idea.

floWenoL fucked around with this message at 02:41 on Dec 23, 2008

# ¿ Dec 23, 2008 02:13

floWenoL: Oct 23, 2002

Zombywuf posted:

Your compiler should decide when to inline the functions. It's probably better at it than you are.

Oh, how cute, it's someone who hasn't ever needed to program for performance!

# ¿ Dec 23, 2008 23:27

floWenoL: Oct 23, 2002

Zombywuf posted:

Never found I could do much better than just telling gcc to do a profiled build. Unless I did it in asm. If you're playing guess-what-the-compiler-will-do you're wasting time.

There's a difference between second-guessing the compiler and making your code amenable to optimization. A compiler (even with profile-driven optimization) is a tool, not an oracle, and dropping down to writing assembly, even when possible, is a dumb move if it's not a last resort.

# ¿ Dec 25, 2008 03:33

floWenoL: Oct 23, 2002

hexadecimal posted:

Personally, I like to do if( n&1 ) to check of it is odd or not. It is probably a lot faster than % operator.

Coding horror right here (if you're actually serious).

Also another one for hexadecimal.txt.

# ¿ Jan 6, 2009 00:21

floWenoL: Oct 23, 2002

hexadecimal posted:

Well, like I said, currently I check for this error in another part of same class. However I agree, that its probably a good idea to generate an exception or some other notification instead of just returning 0.

Why do you even bother checking "o instanceof CVSRevision" if you know only objects of that type will be passed in? The cast would just throw an exception (which is what you want) if you did pass in an object of another type.

I also enjoy !(x ^ y), which is equivalent to x == y.

quote:

Well, like I said, currently I check for this error in another part of same class. However I agree, that its probably a good idea to generate an exception or some other notification instead of just returning 0.

Even if you were absolutely required to return some value, 0 is pretty much the worst value you can return. Really, what were you thinking?

# ¿ Jan 8, 2009 21:01

floWenoL: Oct 23, 2002

Zombywuf posted:

http://gitweb.compiz-fusion.org/?p=...3f547f5d0a4ab1f

The worst thing is that it doesn't even change it++ to ++it.

What's wrong with this?

# ¿ Jan 17, 2009 02:36

floWenoL: Oct 23, 2002

Flobbster posted:

The code is unnecessarily complicated and shows that the developer doesn't understand how the return value of erase can be used in a situation like this.

The correct idiom is (with some syntax liberties because gently caress I'm lazy):

erase returns a valid iterator to the element after the one being erased, or end if it was the last element. There's no reason to drag temporary variables into this to preserve the iterator position.

Eh, that's true, but it's not terribly bad. I didn't think it qualified to be a coding horror.

# ¿ Jan 17, 2009 03:13

floWenoL: Oct 23, 2002

j4cbo posted:

That latter bit was my point - it's fine by the spec for char to be unbounded, and in fact is required for the language to be "actually" Turing-complete.

Unless the spec also bounds stack space (which I don't think it does, given that it doesn't even mandate a stack), the boundedness of pointer size does not mean that C is not Turing-complete. You can "cheat" and use the unbounded stack to do whatever you want (e.g., implement the lambda calculus).

floWenoL fucked around with this message at 05:10 on Apr 13, 2009

# ¿ Apr 13, 2009 05:07

floWenoL: Oct 23, 2002

rhag posted:

As usual, the answer to that is: depends on your project.

Perl is a language suited for certain tasks (and here i'm looking at its legendary strong point: regular expressions), and probably not so suited for others.

Can you build a GUI app with it? Of course. Should you? I doubt it.
Especially since PERL-compatible regex libraries have been created for other languages as well (java, c/c++, python i think)

So, at the end of the day, the questions to be asked are:
- Does my project require certain features that PERL would be a perfect solution?
- Who will code it? Do those people know PERL?Do they wanna know PERL?
- Who will maintain it? Does that team know PERL ?Do they wanna know PERL?

Do you know the difference between Perl 5.x and Perl 6? Or, for that matter, Perl and PERL?

# ¿ May 19, 2009 03:21

floWenoL: Oct 23, 2002

Dijkstracula posted:

To say nothing of that ridiculous switch statement could be removed (edit: or at least simplified) if the author had known about fls()

What is fls()?

Thanks, for some reason the machine I'm on don't have man pages for those. Weird.
vvvv

floWenoL fucked around with this message at 01:54 on Jul 8, 2009

# ¿ Jul 8, 2009 01:42

floWenoL: Oct 23, 2002

Veinor posted:

xkcd is decent (when it's about programming or other nerd stuff) but people reposting it like it's new kills any humor

I wonder if xkcd is lovely today...if only there were a website that would tell me.

# ¿ Jul 22, 2009 09:00

floWenoL: Oct 23, 2002

Bhaal posted:

If you have complex resource building that can fail at multiple points and requires multiple cleanup, it's probably not a good idea to try and house the whole drat thing in one scope. Here's that same logic broken into functions. It has some early returns but if that's an issue we all know ways to solve it, I'm just being lazy.

Obviously you can have much more meaningful function names, but with this you can more easily abstract the surrounding logical branching of where you're at and just focus on one segment at a time. (This would also be one of those times to write a function that you know will only ever get called in a single place).

How very fitting that this was posted in the Coding Horrors thread!

(I still can't decide whether you're trolling or not.)

# ¿ Jul 27, 2009 23:07

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 16:34

floWenoL: Oct 23, 2002

shrughes posted:

See, if it's under construction, it should just go in some private branch. Why don't you use a separate branch for every unit of change you're working on?

Not everyone uses a DVCS, sadly.

# ¿ Sep 12, 2009 23:54

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›2 »

Avenging Dentist posted:

code:

code:

wwb posted:

nebby posted:

quote:

my stepdads beer posted:

FrantzX posted:

code:

crazypenguin posted:

Incoherence posted:

code:

TSDK posted:

quote:

tripwire posted:

Zakalwe posted:

Evis posted:

Lexical Unit posted:

Lexical Unit posted:

BigRedDot posted:

code:

Mustach posted:

code:

quote:

more falafel please posted:

StickGuy posted:

Mustach posted:

quote:

JoeNotCharles posted:

Vanadium posted:

That Turkey Story posted:

BigRedDot posted:

Mustach posted:

Aredna posted:

JoeNotCharles posted:

JoeNotCharles posted:

Mikey-San posted:

That Turkey Story posted:

Zombywuf posted:

Zombywuf posted:

hexadecimal posted:

hexadecimal posted:

quote:

Zombywuf posted:

Flobbster posted:

j4cbo posted:

rhag posted:

Dijkstracula posted:

Veinor posted:

Bhaal posted:

shrughes posted: