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 »

Catalyst-proof: May 11, 2011; better waste some time with you

how!! posted:

I spend my days writing code and fixing bugs. I don't sperg about pristine commit history.

That's super cool. I bet the manager that fires your dumb rear end for committing AWS keys to a publicly accessible repo can't wait to hear all the things you don't sperg about.

# ? Jan 3, 2013 23:03

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 21:17

Mogomra: Nov 5, 2005; simply having a wonderful time

In all fairness, I've committed private credentials to a public repo too.

The very first time I used git and github. At least it was my stuff and not for work. v :shobon:

# ? Jan 3, 2013 23:47

Catalyst-proof: May 11, 2011; better waste some time with you

It's not about the mistake. People are fallible. People make mistakes all the time as part of the learning process. But the only way it's actually a learning process is if you admit it, figure out went wrong, and make steps to correct it, especially in a professional setting, where people are staking their livelihoods on your work. No sane company would let what just happened go by unaccounted for. If your postmortem on a security incident is "not gonna sperg about it lol" then it's obvious it will happen again, especially if the employee who made the mistake doesn't feel like "sperging about" the demonstrably correct thing to do to fix it.

# ? Jan 3, 2013 23:54

Polio Vax Scene: Apr 5, 2009

Wheany posted:

Commented-out code gets deleted on sight.

But what if we need that code someday :ohdear:

# ? Jan 3, 2013 23:56

Pardot: Jul 25, 2001

The real horror is putting configuration or credentials in source code in the first place.

# ? Jan 4, 2013 00:04

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

quote:

The twelve-factor app stores config in environment variables (often shortened to env vars or env)

OK, just replace one horror with another. Got it.

# ? Jan 4, 2013 00:24

hobbesmaster: Jan 28, 2008

Manslaughter posted:

But what if we need that code someday

Obviously the solution is to enclose it in
#ifdef DONOTCOMPILE

#endif

# ? Jan 4, 2013 00:26

Deus Rex: Mar 5, 2005

Pardot posted:

The real horror is putting configuration or credentials in source code in the first place.

I wanted to do this (store credentials, DB hosts, api keys, etc in environment variables) for a new web project -- not just for the security, but for the convenience of configuring different environments for development, staging, etc. Operations refused to work with us on it literally for no reason other than, "We don't want to do it because it'll be more work for us, and the other web teams have always committed credentials to code."

I wonder if anyone ever managed to figure out that .git was accessible for several projects on our certain web hosts, where our Paypal, Amazon AWS, DB credentials and hosts, etc. were all there for the taking in an included php file. (By the way, I discovered and reported that issue to Operations, who proceeded to take the better part of a week to resolve it.)

# ? Jan 4, 2013 00:26

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Suspicious Dish posted:

OK, just replace one horror with another. Got it.

Where's the horror there?

# ? Jan 4, 2013 00:27

geonetix: Mar 6, 2011

Deus Rex posted:

I wanted to do this (store credentials, DB hosts, api keys, etc in environment variables) for a new web project -- not just for the security, but for the convenience of configuring different environments for development, staging, etc. Operations refused to work with us on it literally for no reason other than, "We don't want to do it because it'll be more work for us, and the other web teams have always committed credentials to code."

I wonder if anyone ever managed to figure out that .git was accessible for several projects on our certain web hosts, where our Paypal, Amazon AWS, DB credentials and hosts, etc. were all there for the taking in an included php file. (By the way, I discovered and reported that issue to Operations, who proceeded to take the better part of a week to resolve it.)

I end up just putting the configuration .ini file location in the vhost configuration for webapps. It's one of the sanest way to work thusfar, to be honest. Even if several applications had to share the configuration. But that might be because I haven't run into better solutions yet. At least it keeps the configuration out of source control or deployment systems.

# ? Jan 4, 2013 00:31

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

Ithaqua posted:

TFS really is a wonderful product for those of us who are Microsoft-centric. I want to learn git better, but all of the commands are scary and obtuse.

git-tf is a pretty good starting point if you can work out a sane workflow. I'm still not sure what the best practices is because I end up doing a pull from the repo in both and just committing from master in VS but it's worth it to have local branches instead of a bunch of shelvesets when I need to switch tasks. Also a heap nicer to install than cygwin etc. etc. which was last time I tried to git up windows.

But yeah TFS policies forcing linked work items for check ins is The Selling Point for TFS as far as I'm concerned.

# ? Jan 4, 2013 00:54

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Cocoa Crispies posted:

Where's the horror there?

Environment variables are spawned from parent process to child process, meaning that any configuration you do will propagate along forever.

# ? Jan 4, 2013 00:55

Zamujasa: Oct 27, 2010; Bread Liar

Hammerite posted:

Are you advocating this seriously, or are you ironically suggesting it and assuming it as implicit that it is bad practice? (This is not a sarcastic enquiry. I genuinely do not know.) If the latter, is it not appropriate to add a comment explaining why a particular approach is not used, if an alternate approach exists which might easily occur to someone reading the code but which has non-obvious deficiencies? (This need not involve including commented-out program code.)

Nobody seemed to answer you, so I will :shobon:

quote:

instead of deleting lines, comment them out and add a 2-3 sentence comment above explaining why it was deleted

It was ironic suggestion/snide jab at this post, which implies that documentation and reasoning for changes should be stored in the code and not in the message regarding the changes:

how!! posted:

That seems like an argument in favor of documentation.

Documentation should go in the code, not in the commit history.

Suspicious Dish posted:

Environment variables are spawned from parent process to child process, meaning that any configuration you do will propagate along forever.

You also have to take into account wherever you store these environment variables; for example, one place I was at stored them in Apache's vhost configuration files... which were world-readable. So anybody with ssh access could see all the information for any other hosted site.

I would imagine the best thing to do is designate a .gitignored location for your installation-specific configurations so that it becomes a lot harder to gently caress up and commit them. You just have to be aware of the problem first.

Also, the font on that 12factor site is loving terrible and makes my eyes hurt.

# ? Jan 4, 2013 01:04

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Suspicious Dish posted:

Environment variables are spawned from parent process to child process, meaning that any configuration you do will propagate along forever.

Oh no! Then my worker unicorns will share the same configuration as the master unicorn!

# ? Jan 4, 2013 01:11

Zamujasa: Oct 27, 2010; Bread Liar

php:

<?
$this->_db->query("INSERT INTO awful_table VALUES (?,?,1)",array($foo, $bar));
?>

I wasn't aware people still used VALUES without a column list in this day and age. Certainly makes things fun when the table structure changes!

(This is the third time this particular "feature" has bitten us in the rear end and I really wish the developer that does it would get a clue)

# ? Jan 4, 2013 01:18

X-BUM-RAIDER-X: May 7, 2008

how!! posted:

I've never understood the need people have to sperg out about commit. How often do you *really* have to go back over your history to find a particular commit?

The number of times a bad commit message has negatively effected me: 0.

I had a co-worker a while back who was one of those source control nazis. He'd freak out and yell at you if each commit message wasn't at least 2 sentences. I would always ask him "how does this effect you in any way" and never got an answer.

lol this guy has started posting here. hey guy, that's a bad idea.

# ? Jan 4, 2013 01:26

X-BUM-RAIDER-X: May 7, 2008

wtf this bug, time to reimplement the entire codebase *gets fired for being an idiot*

# ? Jan 4, 2013 01:29

God of Mischief: Oct 22, 2010

I am currently the commit-sperg on my team. I'm not expecting pristine, perfect commits. I just expect the message to describe either the what or why of what was changed, hopefully describing the things that changed in the commit. As long as they don't commit five unrelated changes and only mention one of them in the message I don't care. I have *mostly* won that battle by asking the people who do terrible commit messages what exactly happened in the unrelated files.

# ? Jan 4, 2013 01:50

plashy: Apr 13, 2012

Other than reading the docs/wiki, the first job for a new team member at my work is reading the commit history and seeing how the project was built up, they can read the diffs when it's important. It shows them a lot of stuff that the documentation usually won't and gives them good a piece by piece understanding of the code base.

# ? Jan 4, 2013 02:06

Dicky B: Mar 23, 2004

Troll or not how!!'s post history is an entertaining read

# ? Jan 4, 2013 02:19

Sang-: Nov 2, 2007

At work people tend to commit lots of

code:

//print $var_name

in the code, which I repeatedly point out could be replaced by using the logging modules where

code:

debug($var_name)

doesn't do anything in production but will log when run on development machines.

# ? Jan 4, 2013 02:37

plashy: Apr 13, 2012

Dicky B posted:

Troll or not how!!'s post history is an entertaining read

Was it like...

sdfkjh6;s
djd
buttes
hhhhh

# ? Jan 4, 2013 02:39

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Wheany posted:

Commented-out code gets deleted on sight.

I have a bunch of code that is ugly for performance reasons that's preceded by commented out prettier versions because idiots kept replacing the ugly versions with the pretty version as if I hadn't tried it that way to begin with.

Other than that you are correct.

# ? Jan 4, 2013 03:49

ephphatha: Dec 18, 2009

the talent deficit posted:

I have a bunch of code that is ugly for performance reasons that's preceded by commented out prettier versions because idiots kept replacing the ugly versions with the pretty version as if I hadn't tried it that way to begin with.

Other than that you are correct.

Hopefully with a comment saying "Don't touch the uncommented code, the commented versions are slow as poo poo"?

Edit: Been looking around the code here at the new job while trying to find something to do, and some of it is interesting.

In one of the scripts printing out a table of options:

Perl code:

$divideby = 1;
$count = 1;
foreach (my $entry in $options) {
    $html .= "<td>a checkbox and label using values from $entry</td>";
    if ($count / $divideby == 4) {
        $html .= "</tr>\n<tr>";
        $divideby++;
    }
    $count++;
}

ephphatha fucked around with this message at 04:32 on Jan 4, 2013

# ? Jan 4, 2013 04:17

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

the talent deficit posted:

I have a bunch of code that is ugly for performance reasons that's preceded by commented out prettier versions because idiots kept replacing the ugly versions with the pretty version as if I hadn't tried it that way to begin with.

Other than that you are correct.

Why leave the code there at all? Put a comment at the top of the block of ugly code that explains why it's ugly, remove the pretty code. Problem solved.

# ? Jan 4, 2013 04:19

fritz: Jul 26, 2003

Suspicious Dish posted:

And if you use emacs (lol), use magit. Has a fancy thing for staging/unstaging hunks that's p. awesome.

Guy at this new job saw me using emacs instead of some fancy IDE and literally laughed

WHOIS John Galt posted:

That's super cool. I bet the manager that fires your dumb rear end for committing AWS keys to a publicly accessible repo can't wait to hear all the things you don't sperg about.

How!! is well known for being unemployed, potentially unemployable.

# ? Jan 4, 2013 04:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

fritz posted:

How!! is well known for being unemployed, potentially unemployable.

http://forums.somethingawful.com/showthread.php?threadid=3490971

I think this thread makes clear which one it is.

# ? Jan 4, 2013 04:55

Toady: Jan 12, 2009

How!! is Avenging Dentist's apocalyptic form.

# ? Jan 4, 2013 05:19

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Suspicious Dish posted:

http://forums.somethingawful.com/showthread.php?threadid=3490971

I think this thread makes clear which one it is.

Yep, if someone can't acknowledge why a rationale for a change is invaluable, and thinks that the only thing you can do to code when you work on it is improve it, regardless of your pre existing knowledge of the code's decisions, then I'm pretty sure they aren't gonna be a good fit for most shops. At this point though he strikes me as the IWC of the Cavern of COBOL though.

# ? Jan 4, 2013 05:30

UxP: Aug 27, 2007

Sang- posted:

At work people tend to commit lots of
code:
//print $var_name
in the code, which I repeatedly point out could be replaced by using the logging modules where
code:
debug($var_name)
doesn't do anything in production but will log when run on development machines.

Both of those are equal horrors.

Any code I come across with the hint of print or echo horseshit debug statements is code I don't want to touch. Learn to use a goddamned debugger. If all you use it for is to inspect a variable, you're 90% better than any asshat that doesn't know how to run one.

# ? Jan 4, 2013 06:22

Progressive JPEG: Feb 19, 2003

UxP posted:

Any code I come across with the hint of print or echo horseshit debug statements is code I don't want to touch. Learn to use a goddamned debugger. If all you use it for is to inspect a variable, you're 90% better than any asshat that doesn't know how to run one.

nitpick4u: Debug statements are useful if timing is significant, eg if you're trying to track down the scenario causing a deadlock.

# ? Jan 4, 2013 06:32

het: Nov 14, 2002; A dark black past
is my most valued
possession

UxP posted:

Any code I come across with the hint of print or echo horseshit debug statements is code I don't want to touch. Learn to use a goddamned debugger. If all you use it for is to inspect a variable, you're 90% better than any asshat that doesn't know how to run one.

That doesn't really seem like a reasonable statement to me, sometimes if there's an issue in production that's impossible/impractical to reproduce in engineering we want to raise the log level so we get more debugging output in the log files. Running debuggers on those production systems isn't necessarily a practical solution.

# ? Jan 4, 2013 06:34

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Progressive JPEG posted:

nitpick4u: Debug statements are useful if timing is significant, eg if you're trying to track down the scenario causing a deadlock.

Yeah, working with indexedDB there's a heap of asynchronous stuff going on that a debugger can't effectively keep up with, especially when I need to know the order things are happening is what I think it is. That said though once I'm done working on a feature branch I strip out all the logging calls I was using.

# ? Jan 4, 2013 06:41

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

The horror is committing your printf-debugging statements into your version control.

Your production systems should be logging a bunch of poo poo, but logging is not debugging and if you put your debugging poo poo into the logs your logs rapidly become useless.

# ? Jan 4, 2013 06:41

UxP: Aug 27, 2007

het posted:

That doesn't really seem like a reasonable statement to me, sometimes if there's an issue in production that's impossible/impractical to reproduce in engineering we want to raise the log level so we get more debugging output in the log files. Running debuggers on those production systems isn't necessarily a practical solution.

Raising the log level is not even similar to peppering code with debug statements. It's raising the log level of your logger, which is designed to correctly put the relevant information in a designated and known file or service which you can read or parse later. making GBS threads up code with:

code:

var_dump($_GET);

is what I'm talking about. It's spewing information from wherever you please to wherever it decides to. Commenting them out before committing is a nice touch, but it still proves that you don't know what the gently caress you're doing. Just quit doing it and use the proper methods of information gathering.

# ? Jan 4, 2013 06:42

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

Committing debugging statements is fine. If it's in your own branch.

# ? Jan 4, 2013 06:49

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

Cocoa Crispies posted:

Where's the horror there?

Global variables are great. Hope you didn't want to run a second copy in the same process.

# ? Jan 4, 2013 06:54

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Suspicious Dish posted:

http://forums.somethingawful.com/showthread.php?threadid=3490971

I think this thread makes clear which one it is.

Riiiighhhhtt. He's that guy.

Oh, man. I'm now imagining the new guy coming and rewriting half the code base on Master and committing it as "asdfsababuttes". :psyboom:

Given how smug I'm sure How!!! is in real life, I'm sure the whole situation would be pretty.

# ? Jan 4, 2013 07:12

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Ithaqua posted:

Why leave the code there at all? Put a comment at the top of the block of ugly code that explains why it's ugly, remove the pretty code. Problem solved.

There's comments that explain why it's ugly but people are still always like, 'here i rewrote this as a list comprehension/with a fsm/using a struct'.

# ? Jan 4, 2013 07:23

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 21:17

Bunny Cuddlin: Dec 12, 2004

Suspicious Dish posted:

http://forums.somethingawful.com/showthread.php?threadid=3490971

I think this thread makes clear which one it is.

lol so he's against commit messages because he doesn't actually know how to consume and understand other people's code, so why have messages designed to assist in that? I know people like this.

# ? Jan 4, 2013 07:28

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 »