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!

«‹›1503 »

shrughes: Oct 11, 2008; (call/cc call/cc)

necrobobsledder posted:

If you're doing an Agile development model, you'll be checking in code so often you'll probably hit a point where you'll just check it in and fix it up in another commit happening in only a matter of hours while you work on it.

It's always weird to read things like these, go "WTF?", and then remember how most people still use revision control systems.

# ? Sep 12, 2009 00:42

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 16:01

geetee: Feb 2, 2004; >;[

shrughes posted:

It's always weird to read things like these, go "WTF?", and then remember how most people still use revision control systems.

Maybe setting myself up for embarrassment, but can you explain how people should use revision control systems?

# ? Sep 12, 2009 01:04

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

geetee posted:

Maybe setting myself up for embarrassment, but can you explain how people should use revision control systems?

Don't check in commented out code because you're half done with it. Check in only code that builds.

When you pick up your code tomorrow, use the handy conflict resolution tools that your RCS has! That way, you can see any changes that anyone made to things that your code might have been affected by, and people don't open up a method and go "WTF?" because there's a big block of half-done code in there and they have no idea how to go about modifying the code anymore.

# ? Sep 12, 2009 01:34

Mikey-San: Nov 3, 2005; I'm Edith Head!

Ryouga Inverse posted:

Don't check in commented out code because you're half done with it. Check in only code that builds.

Fun way to stop people from checking in code that breaks the build: set up your VCS to notify a build machine every time someone checks in changes. Have your thankless robot build the project on every commit. When the build fails, your robot fires off an email to everyone:

THE loving PROJECT DOESN'T BUILD NOW
YOU CAN THANK: <PERSON>
BECAUSE OF HIS OR HER CHECK-IN: <REVISION NUMBER>
GO YELL AT THIS PERSON

edit: doesn't stop simple human mistakes, but eventually people get the message and stop doing reckless poo poo

Mikey-San fucked around with this message at 02:25 on Sep 12, 2009

# ? Sep 12, 2009 02:22

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Mikey-San posted:

Fun way to stop people from checking in code that breaks the build: set up your VCS to notify a build machine every time someone checks in changes. Have your thankless robot build the project on every commit. When the build fails, your robot fires off an email to everyone:

THE loving PROJECT DOESN'T BUILD NOW
YOU CAN THANK: <PERSON>
BECAUSE OF HIS OR HER CHECK-IN: <REVISION NUMBER>
GO YELL AT THIS PERSON

quote:

These 3 bears sit in a prominent position and watch our developer�s every move. When things are good we have a green bear gently glowing and purring, when changes are being processed a yellow bear joins the party, and if the build gets broken the growling evil red bear makes an appearance. The developer who broke things usually goes a similar shade of red while frantically trying to fix whatever was broken while the others chortle in the background.

http://blog.last.fm/2008/08/01/quality-control

# ? Sep 12, 2009 02:25

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

shrughes posted:

It's always weird to read things like these, go "WTF?", and then remember how most people still use revision control systems.

Yeah, it's kind of why I think there should be an anti-Pragmatic X series of books - essays on how and why code looks and is created in the wild - under stress, pressure, and just lack of foresight moreso than sheer incompetence.

Ledneh posted:

I tend to agree with you, but as the guy who does a lot of the team's source control stuff, a message to my team: please god just use block comment constructs, I don't care if it's /* or #if 0, just don't use // everywhere

For the case of Java, you don't have much of a choice, and if you use Javadocs, you really don't have much choice but to use // because of nested comments not being supported. My rule is // or # comments that start a line are for block comments only. Problem is, a lot of text editors do an inline comment after a bunch of whitespace to match indenting by default so I'm kind of alone on this.

If you're using Java at work though, you probably have bigger problems to fry than how code is block commented out... like fighting the deep-seated urge to make a noose out of your belt every day.

Ryouga Inverse posted:

Don't check in commented out code because you're half done with it. Check in only code that builds.

Yep, that's part of Agile - make sure the build always loving works at a bare minimum (why this isn't a principle in general or loving obvious in industry is beyond me). I was mostly saying that it's alright to check-in code that's commented out if you basically put a "under construction, here's what's shaky and don't step on these parts" sign up and if it's temporary. In practice, what I've seen happens is people leave TODO comment blocks for ages and ages and it never gets done - it's just not as common with Agile teams.

fletcher posted:

Three bear continuous integration system

Continuous integration is loving fantastic, cheap in every interpretation of the word, easy, and plenty useful for any team. It also gives me excuses to make fun of coworkers or to scream "I got syphilis, yay!" at work and completely freak out anyone.

# ? Sep 12, 2009 02:42

Steve French: Sep 8, 2003

Janin posted:

This applies to #if 0 ... #endif also

Hrm, apparently you're right, at least in vi. I usually use #ifdef NEVER or some other such thing, which keeps syntax highlighting.

Ryouga Inverse posted:

Yeah, checking in commented out code is terrible. You're using source control for that reason, just take it out.

I think this depends somewhat on the context, the team size, and the stage of development. I think that for a small team in early rapid stages of development, that sort of checkin is fine, if its code that for some reason doesn't work right quite yet (or is temporarily non-functional), but will be added soon. Especially if your team is in the habit of doing a lot of small commits; if you know that a piece of code is likely to be used soon, its a lot easier to leave it in there temporarily for other people to see, and not have to go back and dig it out of a previous revision.

Of course, for a more mature project with a larger team, there should be more stringent rules about checking poo poo in, and in those cases checking in commented out code is less reasonable.

# ? Sep 12, 2009 02:46

geetee: Feb 2, 2004; >;[

Ryouga Inverse posted:

Don't check in commented out code because you're half done with it. Check in only code that builds.

Oh! Yeah, that should go without saying

Perhaps you'd like to meet some of my coworkers?

# ? Sep 12, 2009 03:11

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

Ryouga Inverse posted:

Don't check in commented out code because you're half done with it. Check in only code that builds.

Commented-out code doesn't affect whether the project builds :downs:

# ? Sep 12, 2009 03:55

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

Lysidas posted:

Commented-out code doesn't affect whether the project builds

Yes, I'm aware of that. Those were two separate and mutually independent statements; sorry that wasn't very obvious.

Checking in commented out code is almost always bad. The problem is that if it stays there for more than about two commits, it's never going to leave, and then you have this problem where the rest of the codebase changes around this block of commented out code, and now it doesn't make any sense at all.

I would have an example, but I'm not working at the company where I saw the most heinous example of this. Basically, it was a case of code reuse, where they took a previous project and then modified a few things. As stuff got modified, sometimes people would just comment out the old code, presumably so that one could see what it used to do.

But then about five commits down the chain, that old code had nothing to do with what was actually going on anymore, but - surprise! - it was still there, and when I came in to look at the codebase, it made it far harder to understand what was supposed to be going on.

I also had a coworker check in an entire file that didn't build for various reasons, but he had the genius idea to effectively comment it out by removing it from the project. That's why I said both of those things together

# ? Sep 12, 2009 04:32

shrughes: Oct 11, 2008; (call/cc call/cc)

geetee posted:

Maybe setting myself up for embarrassment, but can you explain how people should use revision control systems?

Well, reading things about "checking in code for the night" makes it sound like people are all working on the same branch or something... And having the timescale between "commits" being hours rather than minutes... :/

necrobobsledder posted:

I was mostly saying that it's alright to check-in code that's commented out if you basically put a "under construction, here's what's shaky and don't step on these parts" sign up and if it's temporary.

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?

# ? Sep 12, 2009 15:53

Athas: Aug 6, 2007; fuck that joker

shrughes posted:

Well, reading things about "checking in code for the night" makes it sound like people are all working on the same branch or something... And having the timescale between "commits" being hours rather than minutes... :/

Do you really think it's useful to commit every few minutes?

# ? Sep 12, 2009 15:55

shrughes: Oct 11, 2008; (call/cc call/cc)

Athas posted:

Do you really think it's useful to commit every few minutes?

For some number of minutes less than sixty. And define "commit."

# ? Sep 12, 2009 15:58

Parantumaton: Jan 29, 2009; The OnLy ThInG
i LoVe MoRe
ThAn ChUgGiNg SeMeN
iS gEtTiNg PaId To Be A
sOcIaL MeDiA sHiLl
FoR mIcRoSoFt
AnD nOkIa

Athas posted:

Do you really think it's useful to commit every few minutes?

I'd say that depends on compile times, I personally do a lot of micro-sized commits usually but then again I code Java and we have a CI which runs all the unit tests and builds the entire project after every single commit so (automated) error detection response time for us is usually somewhere around 3 minutes per project. That's partly why we don't even do any branching at our work, there just isn't need for it at our place.

# ? Sep 12, 2009 16:06

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

Sewer Adventure: Aug 25, 2004

Parantumaton posted:

I'd say that depends on compile times, I personally do a lot of micro-sized commits usually but then again I code Java and we have a CI which runs all the unit tests and builds the entire project after every single commit so (automated) error detection response time for us is usually somewhere around 3 minutes per project. That's partly why we don't even do any branching at our work, there just isn't need for it at our place.

What if something breaks in production when you're half way through developing a new feature?

# ? Sep 13, 2009 00:58

Parantumaton: Jan 29, 2009; The OnLy ThInG
i LoVe MoRe
ThAn ChUgGiNg SeMeN
iS gEtTiNg PaId To Be A
sOcIaL MeDiA sHiLl
FoR mIcRoSoFt
AnD nOkIa

Sewer Adventure posted:

What if something breaks in production when you're half way through developing a new feature?

That's the only downside of our "system" at the moment. However when any of our production environmetns break it usually isn't due to the actual code but some related issue like out of memory, typos in templates, some external resource not available etc. I'd say it has happened only like twice or thrice during my time at the company (15 months and counting) when we had to temporarily roll back a feature, replace it with a production-specific fix, commit that, retag the fix, rebuild the software, deploy and then re-add the new/improved feature.

Our chosen general solution for this problem is modularization of our systems with lots and lots of unit tests which has already proven to be a rather good choice for us: For example if Client A has bought from us Products 1 and 2, we create a new project for A which receives 1 and 2 through our own Ivy repository and then we just add client specific code to that project. Doing things this way has allowed us to separate our "critical" code bases with our client code bases so that if production environment breaks, the break is usually caused in the code that's in the client-specific portion and if it isn't, we can separately update the product code, update the Ivy dependency and roll out a new client specific deployment version. This may sound like dependency hell waiting to explode on our faces but in fact it won't since we use Ivy instead of Maven.

Small addentum: One of the reasons we didn't go with branching was that at least Eclipse doesn't handle CVS branches in the most logical way and for some reason our Linux guys couldn't get it to work at all.

But back to coding horrors, I guess.

# ? Sep 13, 2009 10:26

floWenoL: Oct 23, 2002

Parantumaton posted:

I'd say it has happened only like twice or thrice during my time at the company (15 months and counting) when we had to temporarily roll back a feature, replace it with a production-specific fix, commit that, retag the fix, rebuild the software, deploy and then re-add the new/improved feature.

When you say "roll back a feature" do you mean "roll back the current feature in progress" or "roll back all features since the release with the production bug"?

# ? Sep 13, 2009 10:50

Parantumaton: Jan 29, 2009; The OnLy ThInG
i LoVe MoRe
ThAn ChUgGiNg SeMeN
iS gEtTiNg PaId To Be A
sOcIaL MeDiA sHiLl
FoR mIcRoSoFt
AnD nOkIa

floWenoL posted:

When you say "roll back a feature" do you mean "roll back the current feature in progress" or "roll back all features since the release with the production bug"?

Current feature in progress, our unit tests and modularity of systems allow us to rollback only the relevant parts.

# ? Sep 13, 2009 11:08

floWenoL: Oct 23, 2002

Parantumaton posted:

Current feature in progress, our unit tests and modularity of systems allow us to rollback only the relevant parts.

What I'm asking is that if you push out a production fix, do you also push out all completed features since the last release?

# ? Sep 13, 2009 11:11

Parantumaton: Jan 29, 2009; The OnLy ThInG
i LoVe MoRe
ThAn ChUgGiNg SeMeN
iS gEtTiNg PaId To Be A
sOcIaL MeDiA sHiLl
FoR mIcRoSoFt
AnD nOkIa

floWenoL posted:

What I'm asking is that if you push out a production fix, do you also push out all completed features since the last release?

Depends, we can choose to do either.

# ? Sep 13, 2009 12:22

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

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?

Partly because it effectively announces any changes I make that others may rely upon and so they can let me know if there's anything they disagree with faster than if I was in my own little microcosm of the build. That is part of Agile methodology as well. For a really small team, it's not really worth the hassles of private branches and it's just easier to just yell at someone when things bork. If I was on a far larger team, I'd certainly have private branches for sub-projects and efforts, but the way we have works just fine.

Oh, and as mentioned, not everyone has DVCS. Hell, we just moved to Subversion last week. For smaller teams with few dependencies per contributor in the first place and everyone doing work at work really, DVCS is not of much use for us.

# ? Sep 13, 2009 18:44

Sebbe: Feb 29, 2004

Edit: Decided against having this here.

Sebbe fucked around with this message at 22:44 on Sep 13, 2009

# ? Sep 13, 2009 20:22

Athas: Aug 6, 2007; fuck that joker

I like ponies :downs:

Athas fucked around with this message at 06:31 on Sep 14, 2009

# ? Sep 13, 2009 20:51

ohgodwhat: Aug 6, 2005

Is that a programming competition or something? High schoolers trying to program produces some real horrors, like the team that had to print "One Two Three ... Nine Hundred And Ninety Nine" and decided a massive for-switch loop would be appropriate, for every single number. It took them all day and it still didn't pass. That year, as the only person actually programming on my team, we came in first place against other teams of three, beating second place by 50% on score. I suck at programming now and I sucked more then, too.

# ? Sep 14, 2009 03:14

ColdPie: Jun 9, 2006

ryanmfw posted:

Is that a programming competition or something? High schoolers trying to program produces some real horrors, like the team that had to print "One Two Three ... Nine Hundred And Ninety Nine" and decided a massive for-switch loop would be appropriate, for every single number. It took them all day and it still didn't pass. That year, as the only person actually programming on my team, we came in first place against other teams of three, beating second place by 50% on score. I suck at programming now and I sucked more then, too.

This is why I'm so glad I managed to find my current job, working with a small team of highly skilled programmers on a very complex project, in C, with git. There's such a learning curve, the 95% of incompetent programmers, who somehow managed to get honors degrees in Computer Science but think Strings are acceptable substitutes for booleans, will never get in. It's perfect.

# ? Sep 14, 2009 16:35

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

ColdPie posted:

This is why I'm so glad I managed to find my current job, working with a small team of highly skilled programmers on a very complex project, in C, with git. There's such a learning curve, the 95% of incompetent programmers, who somehow managed to get honors degrees in Computer Science but think Strings are acceptable substitutes for booleans, will never get in. It's perfect.

Are you the other 5%? :twisted:

# ? Sep 14, 2009 18:25

CanSpice: Jan 12, 2002; GO CANUCKS GO

Avenging Dentist posted:

Are you the other 5%?

Don't you know that everybody thinks they're in the top 5%?

Edit: Oh wait I see the burn now. Good show, sir.

# ? Sep 14, 2009 21:24

ColdPie: Jun 9, 2006

Avenging Dentist posted:

Are you the other 5%?

Fuuuuuuuuuuuuuuuuuuuuuuuuck :pwn:

# ? Sep 15, 2009 05:46

mr_jim: Oct 30, 2006; OUT OF THE DARK

I don't know if this has been mentioned yet, but I just found out that according to the C standard, a[i] and i[a] are equivalent.

This function:

code:

int foo() {
    char c1 = "abcd"[2];
    char c2 = 2["abcd"];
    return c1 == c2;
}

compiles without errors or warnings, and returns 1.

Having never entered any obfuscated C contests, I was unaware of this.

edit:

code:

#include <stdio.h>
int main() {
    int i, c;
    for (i=0; (c = i["Hello, World!\n"]); i++) {
        putchar(c);
    }
    return 0;
}

mr_jim fucked around with this message at 01:30 on Sep 18, 2009

# ? Sep 18, 2009 01:11

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

mr_jim posted:

I don't know if this has been mentioned yet, but I just found out that according to the C standard, a[i] and i[a] are equivalent.
...

Yep, although I'm pretty sure you'd get clobbered over the head for using the lesser known form in any large body of code. I'm not exactly sure what the underlying reason for this was though. Maybe it was to compete for Fortran users or something? (doubtful it'd help due to C's array row-column conventions that make it awkward for the math purists)

# ? Sep 18, 2009 03:53

mr_jim: Oct 30, 2006; OUT OF THE DARK

quote:

The Committee found no reason to disallow the symmetry that permits a[i] to be written as i[a].

From the "Rationale for ANSI C" (http://www.lysator.liu.se/c/rat/c3.html#3-3-2-1)

Personally, I don't see any reason for array subscripting to be commutative. But I wasn't on the committee.

# ? Sep 18, 2009 04:28

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

necrobobsledder posted:

Maybe it was to compete for Fortran users or something?

Fortran's array indexing, barring specifying index ranges, isn't that different than C's. You certainly can't do i[a] in Fortran, so I don't know what you mean. :confused:

code:

  1         PROGRAM CODINGHORRORSTHREAD
  2 
  3         INTEGER A(100)
  4         A(1) = 12345
  5         1(A) = 42
  6         PRINT *, A(1)
  7         END

~$ gfortran -std=legacy foo.f
foo.f:5.9:

        1(A) = 42                                                       
        1
Error: Invalid character in name at (1)

# ? Sep 18, 2009 04:39

necrobobsledder: Mar 21, 2005; Lay down your soul to the gods rock 'n roll; Nap Ghost

Dijkstracula posted:

Fortran's array indexing, barring specifying index ranges, isn't that different than C's. You certainly can't do i[a] in Fortran, so I don't know what you mean.

I'm talking about row-major v. column-major which was a bit important decades ago for marketability reasons to mathematicians that don't actually know programming itself as a profession and that it's not a big deal if you do the right matrix transforms.

# ? Sep 18, 2009 05:51

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Guys, the a[i] / i[a] equivalence is just because the standard defines a[i] as being equivalent to *(a+i).

# ? Sep 18, 2009 06:08

Bhaal: Jul 13, 2001; I ain't going down alone; Dr. Infant, MD

I coulda swore "offset[index]" was simply treated as referencing the address at "offset + index*element_size". So the trick only worked for data types the compiler was rounding off to whatever the platform was using for a byte.

After messing around on codepad it seems to handle any data type just fine.

# ? Sep 18, 2009 07:20

floWenoL: Oct 23, 2002

Bhaal posted:

I coulda swore "offset[index]" was simply treated as referencing the address at "offset + index*element_size". So the trick only worked for data types the compiler was rounding off to whatever the platform was using for a byte.

After messing around on codepad it seems to handle any data type just fine.

What C data type (other than bitfields) are addressed in units smaller than a byte?

# ? Sep 18, 2009 10:01

Zombywuf: Mar 29, 2008

floWenoL posted:

What C data type (other than bitfields) are addressed in units smaller than a byte?

Heh, like you can comprehend any unit of data size smaller than a megbyte Yegge.

# ? Sep 18, 2009 11:23

mr_jim: Oct 30, 2006; OUT OF THE DARK

Avenging Dentist posted:

Guys, the a[i] / i[a] equivalence is just because the standard defines a[i] as being equivalent to *(a+i).

I understand why they're equivalent. But I also think one could make a case for disallowing that particular syntax, even though it would make writing a compiler slightly more complex. Then again, I doubt "i[a]" ever gets used in real code, so what the harm?

# ? Sep 18, 2009 12:28

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 16:01

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

3. "Just makin' sure."

code:

#ifdef NULL
#undef NULL
#define NULL 0
#endif

2. "Wrapping the wheel."

code:

#ifdef SOME_PLATFORM
typedef unsigned long long plat_ulong64;
#elseif SOME_OTHER_PLATFORM
// etc...
#endif

class ULong64{
    plat_ulong64 value;
public:
    // ...
    friend ULong64 operator + (const ULong64&, const ULong64&);
    // Continue for every operator defined for integer types
};

ULong64 operator + (const ULong64& right, const ULong64& left){
    plat_ulong64 ret = right.value;
    ret += left.value;
    return ULong64(ret);
}

// Continue for every operator defined for integer types

1. "What's the point?"

code:

// ReferencePointer is the crappy in-house attempt at a shared_ptr
return new ReferencePointer<Thing>(blahblah);

# ? Sep 18, 2009 13:56

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!

«‹›1503 »