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 »

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

filter-branch is the main exception, but if you're using filter-branch without a very good grasp of how git works then you're loving insane.

# ? Apr 19, 2013 14:55

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 01:15

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

Strong Sauce posted:

The fact that you can use git stash/git stash apply to save your work is also pretty useful

Woah, I didn't know about git stash. Looks like it could have saved me some headaches from shuffling files around to resolve weird conflicts.

# ? Apr 19, 2013 16:08

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

DaTroof posted:

Woah, I didn't know about git stash. Looks like it could have saved me some headaches from shuffling files around to resolve weird conflicts.

Yeah stash is pretty handy. Although branching and checking out old versions is so painless in git you can go pretty crazy.

git log --graph makes navigating commits easy.

# ? Apr 19, 2013 16:13

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

Presto posted:

The other problem is that it's insidious. Every time I think I finally have a handle on it, it does something that I can't fathom. "OK, I'll just do a pull here and... wait, how can I have a merge conflict in a file that I haven't loving touched?"

This can happen if you have your editor set up to mess with files when opening them (or when saving them without any changes), or you're in the habit of committing files without doing a once-over review of what you're committing, or if you did the once over and committed irrelevant changes while giving no fucks.

Whatever the case may be, git provides you the necessary diff tracking to find out what happened and learn from it so you should do that. And god help you if you believe hacking a CVS repo is a reasonable recovery option.

Gazpacho fucked around with this message at 21:32 on Apr 19, 2013

# ? Apr 19, 2013 17:27

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

Hahaha, all this time when I would get warnings to "stash or commit your changes," I didn't realize "stash" was a git command instead of a non-specific recommendation. :downs:

# ? Apr 19, 2013 18:10

PrBacterio: Jul 19, 2000

Huh. Well I guess I'll just take the preceding couple of pages of discussion as vindication of my decision to use Mercurial over git :colbert:

# ? Apr 19, 2013 18:38

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

PrBacterio posted:

Huh. Well I guess I'll just take the preceding couple of pages of discussion as vindication of my decision to use Mercurial over git

High Five! Although I use the fetch extension insted of rebase because I'm worried something will gently caress up so my repo is literred with commits that just say "Automated merge with blah blah".

# ? Apr 19, 2013 19:07

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

git is pretty nice tech, but I wish the tools were more consistent.

git branch -d $foo, git tag rm $foo, git format-patch emitting a series of patches when given a single commit.

It seems that it was haphazardly developed over time, and I'm curious what would happen if somebody made a new git client based on libgit2 or something.

# ? Apr 20, 2013 03:42

kitten smoothie: Dec 29, 2001

Suspicious Dish posted:

git is pretty nice tech, but I wish the tools were more consistent.

git branch -d $foo, git tag rm $foo, git format-patch emitting a series of patches when given a single commit.

It seems that it was haphazardly developed over time, and I'm curious what would happen if somebody made a new git client based on libgit2 or something.

Yep, this is stuff is a little annoying.

http://stevelosh.com/blog/2013/04/git-koans/

quote:

�How can I view a list of all tags?�

�git tag�, replied Master Git.

�How can I view a list of all remotes?�

�git remote -v�, replied Master Git.

�How can I view a list of all branches?�

�git branch -a�, replied Master Git.

�And how can I view the current branch?�

�git rev-parse --abbrev-ref HEAD�, replied Master Git.

�How can I delete a remote?�

�git remote rm�, replied Master Git.

�And how can I delete a branch?�

�git branch -d�, replied Master Git.

The novice thought for a few moments, then asked: �Surely some of these could be made more consistent, so as to be easier to remember in the heat of coding?�

Master Git snapped his fingers. A hobgoblin entered the room and ate the novice alive. In the afterlife, the novice was enlightened.

# ? Apr 20, 2013 04:20

Opinion Haver: Apr 9, 2007

Zaphod42 posted:

Yeah stash is pretty handy. Although branching and checking out old versions is so painless in git you can go pretty crazy.

git log --graph makes navigating commits easy.

I can't remember where I picked these up, but having these aliases is incredibly handy:

code:

[alias]
        lol = log --graph --decorate --pretty=oneline --abbrev-commit
        lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

# ? Apr 20, 2013 04:49

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Personally I am a fan of this alias. "git lg" Found it on Coderwall somewhere and modified it to show the date and how long ago it was modified. Nothing to back this up, but I feel the color/highlights have improved my use of git immensely. I'm always confused sometimes about why people can't follow the repo and then I have to look at a plan old `git log` and remember why.

doing `git lg -p` is awesome.

[alias]
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %C(green)(%cr, %cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=short

It is really awesome to see your repo expanding and contracting with people's merges.

This only works if you are a more recent version of OSX that supports 256 colors in terminal.

# ? Apr 20, 2013 17:30

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

On that note, I find it virtually impossible to get any work done without having gitk --all open.

# ? Apr 20, 2013 17:35

Doctor w-rw-rw-: Jun 24, 2008

This thread is now the version control thread. :|

Can we get back to the horrors?

# ? Apr 20, 2013 18:02

Presto: Nov 22, 2002; Keep calm and Harry on.

Gazpacho posted:

This can happen if you have your editor set up to mess with files when opening them (or when saving them without any changes), or you're in the habit of committing files without doing a once-over review of what you're committing, or if you did the once over and committed irrelevant changes while giving no fucks.

Except I've had it complain about files that I have literally never looked at. Because they're java. :v:

quote:

Whatever the case may be, git provides you the necessary diff tracking to find out what happened and learn from it so you should do that. And god help you if you believe hacking a CVS repo is a reasonable recovery option.

I didn't say it was reasonable, only that it was possible.

And once I had git completely throw away a whole bunch of commits I had just done like they never existed. I'm sure it was something I did, but there's no way to figure out what.

Look, I'm just a CVS guy trapped in a git world, OK? :colbert:

# ? Apr 20, 2013 19:11

Arcsech: Aug 5, 2008

Is it a horror if it was made specifically to explore how horrific something could become?

Behold, functional programming in C.

# ? Apr 20, 2013 20:36

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Arcsech posted:

Is it a horror if it was made specifically to explore how horrific something could become?

Behold, functional programming in C.

I wonder if they realize that people are going to want to use this in real projects? Are they aware of the horror they have unlocked?

:negative:

# ? Apr 20, 2013 20:52

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

I wish I could find the project I came across years ago, where someone had built a lazy computation system in C++ out of logical operators.

# ? Apr 20, 2013 21:59

nielsm: Jun 1, 2009

Arcsech posted:

Is it a horror if it was made specifically to explore how horrific something could become?

Behold, functional programming in C.

What does this do that C++11 doesn't?

(Let me guess, it's not called C++.)

# ? Apr 20, 2013 22:52

bucketmouse: Aug 16, 2004; we con-trol the ho-ri-zon-tal
we con-trol the verrr-ti-cal

Volmarias posted:

I wonder if they realize that people are going to want to use this in real projects? Are they aware of the horror they have unlocked?

Isn't this basically how objective-c started?

# ? Apr 20, 2013 22:56

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

nielsm posted:

What does this do that C++11 doesn't?

(Let me guess, it's not called C++.)

Well for one it's pure C... pretty big difference between C and C++.

# ? Apr 21, 2013 13:46

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

I'm taking a pretty basic OOP course at the university, and there is nothing special about the lectures. But excercise sessions are pretty fun. This week we had to impelement Conway's game of life (in Java) without using if, switch or try. The idea was to take single responsibility principle to the extreme.

It was a fun excercise IMO, and my partner and I managed to get pretty far by writing a pretty silly/terrible inheritance hierarchy.

During the excercise, we had a quick break for discussion about what people thought about the excercise and one guy said that it was interesting to write good code such as this that does not use ifs.

So beware, "conditional statements considered harmful" might become a thing. (Don't worry, I objected to his statement of the code being good because it does not use ifs)

# ? Apr 21, 2013 18:24

zeekner: Jul 14, 2007

Wheany posted:

I'm taking a pretty basic OOP course at the university, and there is nothing special about the lectures. But excercise sessions are pretty fun. This week we had to impelement Conway's game of life (in Java) without using if, switch or try. The idea was to take single responsibility principle to the extreme.

It was a fun excercise IMO, and my partner and I managed to get pretty far by writing a pretty silly/terrible inheritance hierarchy.

During the excercise, we had a quick break for discussion about what people thought about the excercise and one guy said that it was interesting to write good code such as this that does not use ifs.

So beware, "conditional statements considered harmful" might become a thing. (Don't worry, I objected to his statement of the code being good because it does not use ifs)

I wouldn't worry about bad habits coming from a first or second year CS student, that's gonna happen no matter what. They'll eventually grow out of it, and probably replace that stupid habit with other stupid things like single-point-of-return.

I had a professor that was on a kick about SPOR, so I would intentionally include at least one multiple return statement in every project and defend it during presentation/code review. He was a pretty chill dude, though.

# ? Apr 21, 2013 19:05

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Wheany posted:

So beware, "conditional statements considered harmful" might become a thing. (Don't worry, I objected to his statement of the code being good because it does not use ifs)

It already is. I actually don't think it's completely insane so much as that it needs a language designed around the idea of not needing explicit conditionals.

# ? Apr 21, 2013 19:44

QuarkJets: Sep 8, 2008

Salvador Dalvik posted:

I wouldn't worry about bad habits coming from a first or second year CS student, that's gonna happen no matter what. They'll eventually grow out of it, and probably replace that stupid habit with other stupid things like single-point-of-return.

I had a professor that was on a kick about SPOR, so I would intentionally include at least one multiple return statement in every project and defend it during presentation/code review. He was a pretty chill dude, though.

I had a coworker throw a SPOR comment at me the other day. He accused me of writing spaghetti code because I had three different spots where a function could return something. It's not as though the logic is hard to understand, but apparently if you're using more than one return then that just fucks with some peoples' heads I guess.

e:

code:

def my_function(some_dict):
  if isinstance(some_dict,dict):
    if "poop" in some_dict:
      return True
    elif "crap" in some_dict:
      return True
  return False

SPAGHETTI CODE :siren:

QuarkJets fucked around with this message at 20:13 on Apr 21, 2013

# ? Apr 21, 2013 20:09

nielsm: Jun 1, 2009

QuarkJets posted:

I had a coworker throw a SPOR comment at me the other day. He accused me of writing spaghetti code because I had three different spots where a function could return something. It's not as though the logic is hard to understand, but apparently if you're using more than one return then that just fucks with some peoples' heads I guess.

Even for things like "filter out unwanted cases" where you have a series of simple "if not blah: return", instead of a pyramid of "if blah: if bleh: ..."
Eww.

QuarkJets posted:

code:

def my_function(some_arg):
  if isinstance(some_arg,dict):
    if "poop" in some_arg:
      return True
  return False

SPAGHETTI CODE :siren:

Arguably:

Python code:

def my_function(some_arg):
  return isinstance(some_arg,dict) and "poop" in some_arg

But your actual code probably isn't that simple.

# ? Apr 21, 2013 20:14

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

Don't use isinstance. Please.

# ? Apr 21, 2013 20:17

Lurchington: Jan 2, 2003; Forums Dragoon

that seems like a bit of a broad brush, but I'll say that if this is python we're talking about, it's always good to using collections.Mapping instead of dict in 'isinstance' checks:
http://docs.python.org/2/library/collections.html#collections-abstract-base-classes

# ? Apr 21, 2013 20:21

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

Lurchington posted:

that seems like a bit of a broad brush, but I'll say that if this is python we're talking about, it's always good to using collections.Mapping instead of dict in 'isinstance' checks:
http://docs.python.org/2/library/collections.html#collections-abstract-base-classes

or just don't use it at all and don't completely miss the point of duck typing

# ? Apr 21, 2013 20:26

QuarkJets: Sep 8, 2008

Suspicious Dish posted:

Don't use isinstance. Please.

Why not?

# ? Apr 21, 2013 20:45

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Wheany posted:

I'm taking a pretty basic OOP course at the university, and there is nothing special about the lectures. But excercise sessions are pretty fun. This week we had to impelement Conway's game of life (in Java) without using if, switch or try. The idea was to take single responsibility principle to the extreme.

It was a fun excercise IMO, and my partner and I managed to get pretty far by writing a pretty silly/terrible inheritance hierarchy.

During the excercise, we had a quick break for discussion about what people thought about the excercise and one guy said that it was interesting to write good code such as this that does not use ifs.

So beware, "conditional statements considered harmful" might become a thing. (Don't worry, I objected to his statement of the code being good because it does not use ifs)

I notice that there was no mention made of while or for.

code:


boolean ret = someFunc();
for(;ret;;){
  something();
  break;
}

while(ret){
  something();
  break;
}

# ? Apr 21, 2013 20:49

Lurchington: Jan 2, 2003; Forums Dragoon

Jonnty posted:

or just don't use it at all and don't completely miss the point of duck typing

This seems to be the worst combination of unhelpful and rude.

in answer to QuarkJets:
This seems like a decently laid-out (and only a bit snarky) of a description why isinstance isn't the best way to go about most things: http://www.canonical.org/~kragen/isinstance/

# ? Apr 21, 2013 20:54

QuarkJets: Sep 8, 2008

Lurchington posted:

This seems to be the worst combination of unhelpful and rude.

in answer to QuarkJets:
This seems like a decently laid-out (and only a bit snarky) of a description why isinstance isn't the best way to go about most things: http://www.canonical.org/~kragen/isinstance/

So if you want to use several of the interfaces that are available in dict, it's preferable to check for these one-by-one or wrap everything in a try block instead of just using isinstance? And this is because you may want to pass something that looks like a dict but doesn't actually inherit from dict? That simultaneously feels more and less pythonic.

Reading through the collections module, would there be something wrong with using:

code:

 isinstance(x,collections.Mapping)

if I wanted to guarantee that object x implements at least all of the same interfaces as dict? This implements the attribute checking that has been alluded to but in a far cleaner way, and it allows users to pass their own dict-like non-dict-inheriting objects, no? This seems like the ultimate "pythonic" solution if you're using types that are described in collections

# ? Apr 21, 2013 21:20

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

nielsm posted:

Even for things like "filter out unwanted cases" where you have a series of simple "if not blah: return", instead of a pyramid of "if blah: if bleh: ..."
Eww.

Ugh, reminds me of a job where these two styles where mixed. All the code looked like this:

code:

if(blah)
	return ERROR;

if(blah2) {
	if(blah3)
		return ERROR;
	if(!blah4) {
		return ERROR;
	} else {
		if(blah5) {
			//do real work here
		} else {
			return ERROR
		}
	}
} else {
	return ERROR;
}
return NO_ERROR;

Basically no consistency at all. Sometimes check for the error condition, sometimes check for the no error condition, and the real work block is large enough that it doesn't all fit on the screen, so you have to read through everything to just find out what the function expects in order to not throw an error. And of course the "real work" part has its own if/elses which you have to check every time in order to see if it's an error condition check or actual control flow. Every function I worked on I changed to

code:

if(blah)
	return ERROR;
if(blah2)
	return ERROR;
if(blah3)
	return ERROR;
...

//do real work here

return NO_ERROR;

before proceeding.

# ? Apr 21, 2013 21:35

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

QuarkJets posted:

So if you want to use several of the interfaces that are available in dict, it's preferable to check for these one-by-one or wrap everything in a try block instead of just using isinstance? And this is because you may want to pass something that looks like a dict but doesn't actually inherit from dict? That simultaneously feels more and less pythonic.

Sorry, I'll be less snarky this time. The one-by-one interface check you're proposing is basically "calling the method" - it'll fail if any of the dict interface that you're using isn't there. If you're legitimately passing something that isn't a dict into a function that takes a dict, you probably want to change how you're doing things, although I suppose there may be valid reasons for it, so if you need to then wrap everything in a try-catch. But yeah, that's the point of duck typing - if it looks like a duck, quacks like a duck, then treat it like a duck. If you want static typing and big inheritance hierarchies, go for Java or C#.

Jonnty fucked around with this message at 22:05 on Apr 21, 2013

# ? Apr 21, 2013 22:01

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

You should always know what you got passed. If this function takes a dict-like, it can safely make the assumption that it will never be passed a not-dict-like, and if somebody makes that problem, it's their bug to fix.

# ? Apr 21, 2013 22:28

QuarkJets: Sep 8, 2008

Jonnty posted:

Sorry, I'll be less snarky this time. The one-by-one interface check you're proposing is basically "calling the method" - it'll fail if any of the dict interface that you're using isn't there. If you're legitimately passing something that isn't a dict into a function that takes a dict, you probably want to change how you're doing things, although I suppose there may be valid reasons for it, so if you need to then wrap everything in a try-catch. But yeah, that's the point of duck typing - if it looks like a duck, quacks like a duck, then treat it like a duck. If you want static typing and big inheritance hierarchies, go for Java or C#.

But isinstance(x,collections.Mapping) is a nice and simple way to use duck typing that also lets you prepare for non-ducks, right? If I'm concerned that some user might call my code with nonsensical arguments, then I should make sure that the code knows how to handle nonsensical arguments. Using a try/except block or an isinstance(x,collections.Mapping) check seems equivalent to me, if we're talking about dicts specifically.

You've suggested that I should just assume that the argument is dict-like and let an exception get raised if it's not, but that's not always a desired outcome... and sometimes it's even sloppy. For instance, if this is part of a computational suite that takes 6 hours to run, and this particular method just prints some stuff to the terminal at the end of those 6 hours, then I probably don't want the code to stop running just because I failed to print something to the terminal. "That's why you can use try/except" you say, but an isinstance(obj,collections.Mapping) would seemingly do the job just as well

If you're the only one who's ever going to use your code, then feel free to just assume that a given argument has specific attributes

QuarkJets fucked around with this message at 22:37 on Apr 21, 2013

# ? Apr 21, 2013 22:34

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

QuarkJets posted:

If I'm concerned that some user might call my code with nonsensical arguments, then I should make sure that the code knows how to handle nonsensical arguments.

This is known as "safe argument checking" and it's considered a bad practice nowadays. If somebody hands you a bad thing, it's their error, not yours. Even if you make sure that it's a mapping, it's possible for somebody to hand you an "invalid object", and an isinstance won't save you and you'll crash regardless. Making the assumption that arguments that are passed to you are valid prevents you from having to do all of that effort yourself, and lets you say "if I get bad input, I'll have undefined behavior", which is an extremely useful thing.

Suspicious Dish fucked around with this message at 22:56 on Apr 21, 2013

# ? Apr 21, 2013 22:54

QuarkJets: Sep 8, 2008

Suspicious Dish posted:

This is known as "safe argument checking" and it's considered a bad practice nowadays. If somebody hands you a bad thing, it's their error, not yours. Even if you make sure that it's a mapping, it's possible for somebody to hand you an "invalid object", and an isinstance won't save you and you'll crash regardless. Making the assumption that arguments that are passed to you are valid prevents you from having to do all of that effort yourself, and lets you say "if I get bad input, I'll have undefined behavior", which is an extremely useful thing.

This seems inefficient in some computational cases, such as the one that I described. While I can understand this practice being employed in general, I dislike the idea of a user wasting an afternoon of computing resources just because they fed my code some invalid input. You can't always catch invalid input, but there are some simple cases where a quick isinstance() could potentially save a lot of computing time.

If they pass invalid input to the computational portions of the code then to hell with them

# ? Apr 21, 2013 23:01

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Suspicious Dish posted:

This is known as "safe argument checking" and it's considered a bad practice nowadays.

Maybe in Python circles

# ? Apr 21, 2013 23:07

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 01:15

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

QuarkJets posted:

I dislike the idea of a user wasting an afternoon of computing resources just because they fed my code some invalid input.

Well good thing your example is made up.

What exactly do you plan on doing with the wrong kind of input?

What if the wrong kind of input is wrong in a way you did not anticipate? Is it now okay to have wasted an afternoon of computing resources?

# ? Apr 21, 2013 23:15

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 »