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 »

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Volmarias posted:

Well, thank you for explaining what's going on, but I still don't buy that it's a good idea. Let "exit" be a keyword that exits the interpreter immediately, perhaps with a "goodbye!" message for clarity.

I can appreciate why you might consider that a better approach, and it is a matter of opinion. I think the language designers just want to be parsimonious with the special statement forms that they allow into the language.

# ? Sep 7, 2013 20:43

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 16:25

Scaevolus: Apr 16, 2007

Hammerite posted:

And they can't really cause evaluation of its string representation to make the interpreter exit, because well, I shouldn't have to explain why that would be a bad idea. See:

I dunno, I think it's a great idea!

code:

$ python
Python 2.7.3 (default, Jan  2 2013, 13:56:14) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Exit(object):
...     def __repr__(self):
...             import sys
...             sys.exit(0)
... 
>>> exit = Exit()
>>> locals()
{'Exit': <class '__main__.Exit'>, '__builtins__': <module '__builtin__' (built-in)>, '__package__': None, 'exit': $

Scaevolus fucked around with this message at 21:25 on Sep 7, 2013

# ? Sep 7, 2013 21:22

evensevenone: May 12, 2001; Glass is a solid.

Yeah, you don't want to end up like MATLAB where naming a variable "quit" means you can't close the IDE.

# ? Sep 7, 2013 21:39

Tesseraction: Apr 5, 2009

Pretty much. I think it's a relatively non-obnoxious way of saying "this isn't part of the language, please use the language version or a relevant interrupt."

I mean when you think about it, someone who knows what they're doing can just hit Ctrl+d, but letting people use 'exit' despite it not being a method call is patronising to the point of encouraging bad design (as in, omitting brackets from a method despite that being mandatory for the language).

It's similar to the print x vs. print(x) issue between 2.x and 3.x, really. Those of us who know how programming work will prefer the 'easier' solution but really making idiot-proof shortcuts can lead to idiot-full programs.

# ? Sep 7, 2013 23:27

Pythagoras a trois: Feb 19, 2004; I have a lot of points to make and I will make them later.

Tesseraction posted:

It's similar to the print x vs. print(x) issue between 2.x and 3.x, really. Those of us who know how programming work will prefer the 'easier' solution but really making idiot-proof shortcuts can lead to idiot-full programs.

I was just about to bring up print and print() - as far as I see it, it's one of those "you're not wrong, you're just an rear end in a top hat" type situations. Yeah, there's an abstract and difficult to quantify coding ethos that state print should technically be a function and not a statement, I get that. I also get that it's a fan disservice to ignore that you're breaking an entire generation's first helloworld program because of an abstract and difficult to quantify coding ethos.

Despite my strong opinions about Py3 not being backwards compatible with the print statement, I admit I'm very human and write terrible code from time to time. For anyone who uses Django you might appreciate this iterative process where I came to the conclusion I was doing things the hard way:

code:

def newCounty(request):
	if request.method == "POST":
		form = CountyForm(request.POST)
		if form.is_valid():
			new_save = County(**form.cleaned_data)
			new_save.save()
			return HttpResponseRedirect(reverse('counties:detailcounty',
								 args=(new_save.id,) ))
		else:
			return render(
				request,
				'counties/new_county.html',
				{'form':form, 'error':'Your Form Was Not Valid'})
	else:
		form = CountyForm()
		return render(request, 'counties/new_county.html', {'form':form})

It became apparent **form.cleaned_data was probably me trying too hard, and maybe the builtin error codes are good enough:

code:

def newCounty(request):
	if request.method == "POST":
		form = CountyForm(request.POST)
		if form.is_valid():
			new_save = form.save()
			return HttpRequestRedirect(reverse('home'))
		else:
			return render(request, 'counties/new_county.html', {'form':form})
	else:
		form = CountyForm()
		return render(request, 'counties/new_county.html', {'form':form})

And then I learned that class based views does all that crap for you:

code:

class newCounty(FormView):
	model = County
	template_name = 'counties/new_county.html'

Welp, at least I spent a month learning how complicated things would be if Django didn't do CRUD for you out of the box!

Pythagoras a trois fucked around with this message at 01:11 on Sep 8, 2013

# ? Sep 8, 2013 00:58

God of Mischief: Oct 22, 2010

Ithaqua posted:

One of my friends recently got a job where the business routinely says, "We don't mind if it takes longer, we're more concerned with quality and improving our process".

I accused him of getting a job in Bizarro World.

That is my current job. What your buddy didn't mention is that this is actually code for "we are being micromanaged so deeply on incredibly unimportant details while the greater business rules are undefined that we will never actually launch a single product."

Also: feature creep based on what the CEO's buddy thinks would be neat.

# ? Sep 8, 2013 01:16

raminasi: Jan 25, 2005; a last drink with no ice

So if "We don't mind if it takes longer" means "We're being micromanaged to hell," and "Our focus is on delivery and" means "We have no plan to manage technical debt," what's the secret code for an actual good place to work? Or are we all just hosed?

# ? Sep 9, 2013 01:51

megalodong: Mar 11, 2008

GrumpyDoctor posted:

So if "We don't mind if it takes longer" means "We're being micromanaged to hell," and "Our focus is on delivery and" means "We have no plan to manage technical debt," what's the secret code for an actual good place to work? Or are we all just hosed?

The secret is to never work in IT in any form.

# ? Sep 9, 2013 02:09

npe: Oct 15, 2004

GrumpyDoctor posted:

So if "We don't mind if it takes longer" means "We're being micromanaged to hell," and "Our focus is on delivery and" means "We have no plan to manage technical debt," what's the secret code for an actual good place to work? Or are we all just hosed?

There isn't any set of words for this, probably because if there was it would be quickly subverted by lovely places to work and would become a euphemism for something else.

The reality is that a properly managed team will be constantly evaluating the cost/benefit of making progress on outward features vs managing technical debt. This means even in a healthy environment, this fight never truly goes away - it's more that you engage in the debate on an ongoing basis. Good teams find themselves asking a lot of "I can fix this very quickly, but it could lead to problems later. Is it worth it now to take the longer way to do it right?" And the answer will vary quite a bit, depending on the variables.

Teams that have hard and fast answers in one direction or another, you should be wary of.

# ? Sep 9, 2013 03:45

QuarkJets: Sep 8, 2008

evensevenone posted:

Yeah, you don't want to end up like MATLAB where naming a variable "quit" means you can't close the IDE.

MATLAB is a coding horror

# ? Sep 9, 2013 04:58

Innocent Bystander: May 8, 2007; Born in the LOLbarn.

MATLAB is the siren song of the scientific community.

# ? Sep 9, 2013 07:29

Pilsner: Nov 23, 2002

Bognar posted:

This is an issue for a few select people here. They treat source control more as a way to save your work at the end of the day, rather than a series of individual modifications, and think that it's too much work to commit after each logical set of changes.

Maybe it's because I'm used to the check out-check in style source control (TFS etc.), but can you explain why you think it's so important to commit in small connected clumps? If you say "so you can revert changes", I'm going to ask how often you really need to do that, and how you're going to revert a single logical change made 500 commits ago in the middle of everything.

It's not that I mind lots of commits at all, they do no harm, but I also don't see what good they actually do. It sounds more like a :colbert:

principle

, which sometimes overrules rationality. But maybe I'm wrong.

# ? Sep 9, 2013 09:33

it is: Aug 19, 2011; by Smythe

The real reason you make little commits all the time is that it minimizes the amount of time your code differs from master

# ? Sep 9, 2013 09:35

hirvox: Sep 8, 2009

Pilsner posted:

Maybe it's because I'm used to the check out-check in style source control (TFS etc.), but can you explain why you think it's so important to commit in small connected clumps?

In addition to the merge issue with larger changes, some programmers have an annoying tendency to commit multiple changes at the same time, even if they logically are separate. If the same commit has ten improvements and five bugs, you'll have to redo some of the work just to get the master copy back to a known good state. Or if the same commit has feature A and feature B, you're in trouble if the higher-ups only want feature B to go live in your next deployment.

# ? Sep 9, 2013 09:45

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

Please do not just clump all your changes into one commit. If I have to git bisect and end up at a huge commit diff I will kill myself (and the programmer who was doing it too).

Commits should be small, descriptive, and grouped by what they're changing. You might have to end up running against more commits with git bisect (and not that much anyways since it reduces the search space by half everytime), but at least you won't be tearing your hair out over what part of the commit is buggy.

Also you will hate your teammates when you have to undo their change, but then also include X files except for 1 to insert in all the working features of that commit.

# ? Sep 9, 2013 09:51

Pilsner: Nov 23, 2002

All I can say is that I've been working with a team using TFS for 7 years, and all of your points are completely foreign to me. I can see what you mean theoretically, but not practically, as in "oh yeah that's a problem we have often". Maybe you work in a completely different fashion with a DVCS.

# ? Sep 9, 2013 09:58

hirvox: Sep 8, 2009

Pilsner posted:

All I can say is that I've been working with a team using TFS for 7 years, and all of your points are completely foreign to me. I can see what you mean theoretically, but not practically, as in "oh yeah that's a problem we have often". Maybe you work in a completely different fashion with a DVCS.

I primarily work with TFS too, and I've personally encountered the two issues I mentioned several times. The new UI that recontextualizes shelvesets as suspend/resume work helps somewhat.

# ? Sep 9, 2013 10:03

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

Pilsner posted:

Maybe it's because I'm used to the check out-check in style source control (TFS etc.), but can you explain why you think it's so important to commit in small connected clumps?

Reviewability, making each change simple and focused enough that it can be reviewed without much effort. What I've seen happen in more than one organization is that devs can't effectively review each other because the changesets are too complex. They might rubberstamp each other, or buck the commit policy, or just block for hours/a day until they get the review.

I don't know how other devs approach features. Maybe I'm surrounded by devs who know how to mange their coding time so that at 5PM every day (and no sooner!) they have a robust changeset that is 100% coherent, ready to deploy to production, no unverified assumptions that might have to be reworked later along with downstream code that depends on them, but still simple enough that their peers can legitimately review it within 5 minutes. I'm not one of those devs.

Gazpacho fucked around with this message at 10:51 on Sep 9, 2013

# ? Sep 9, 2013 10:38

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Pilsner posted:

All I can say is that I've been working with a team using TFS for 7 years, and all of your points are completely foreign to me. I can see what you mean theoretically, but not practically, as in "oh yeah that's a problem we have often". Maybe you work in a completely different fashion with a DVCS.

It may be my own misadventures with TFS was poor, but I always had a hard time finding when a particular change happened and what happened with it. How do you do it?

Perhaps another reason in TFS to minimize changes is to reduce how many different files you have checked out in some fashion. That kind of assumes you have those jackasses that lock everything when they edit.

# ? Sep 9, 2013 14:17

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

Pilsner posted:

All I can say is that I've been working with a team using TFS for 7 years, and all of your points are completely foreign to me. I can see what you mean theoretically, but not practically, as in "oh yeah that's a problem we have often". Maybe you work in a completely different fashion with a DVCS.

When trying to find out why a blob of code is doing some non-obvious thing, how often do you find the source control history to be of use?

# ? Sep 9, 2013 14:39

hirvox: Sep 8, 2009

Rocko Bonaparte posted:

It may be my own misadventures with TFS was poor, but I always had a hard time finding when a particular change happened and what happened with it. How do you do it?

On a per-file basis, there's the Annotate option. It shows the last changeset to touch each line in a file. There's also the Track Changeset option, which shows how the changeset was merged from one branch to another.

IMHO the best way to keep track of everything to have good commit messages (short summary of what changed and why) combined with associating every single changeset with the appropriate work item. Visual Studio's version history and merge views don't show the latter, but the extra context is there if you dig for it.

# ? Sep 9, 2013 14:48

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

Rocko Bonaparte posted:

It may be my own misadventures with TFS was poor, but I always had a hard time finding when a particular change happened and what happened with it. How do you do it?

Perhaps another reason in TFS to minimize changes is to reduce how many different files you have checked out in some fashion. That kind of assumes you have those jackasses that lock everything when they edit.

TFS doesn't lock anything except binary files by default, although it's configurable and anyone who configures "full lock on checkout" is wrong and horrible.

The best way to have easily traceable changesets in TFS is to leverage work items properly -- if you have PBIs/user story work items with a bunch of child tasks, it's easy to enforce "Each checkin must be tied to a work item", and then you just tie each changeset to a task when you perform your checkin. Then you can look at that PBI and see all of the changesets done for each of the tasks.

Of course, you can still see the entire change history for any particular file or folder in TFS, regardless of whether it's tied to a work item or not.

# ? Sep 9, 2013 14:51

kitten smoothie: Dec 29, 2001

it is posted:

The real reason you make little commits all the time is that it minimizes the amount of time your code differs from master

This. I got burned once and now I do my work on a branch that I do lots of little commits on and rebase from master every morning. Never again do I want to spend a whole day resolving merge conflicts.

# ? Sep 9, 2013 14:51

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

kitten smoothie posted:

This. I got burned once and now I do my work on a branch that I do lots of little commits on and rebase from master every morning. Never again do I want to spend a whole day resolving merge conflicts.

rebasing from master every morning doesn't depend on you doing lots of little commits does it? Couldn't you just rebase from master everyday and still avoid the huge merge?

# ? Sep 9, 2013 15:37

HFX: Nov 29, 2004

I use little commits and lots of topic branches for the following reasons:

It makes merging easier.
It makes bisections easier.
It makes reviews easier.
It improves design history.
It makes feature sets more divisible.

# ? Sep 9, 2013 16:39

JawnV6: Jul 4, 2004; So hot ...

Plorkyeran posted:

When trying to find out why a blob of code is doing some non-obvious thing, how often do you find the source control history to be of use?

teach you not want don't provide

# ? Sep 9, 2013 18:36

Qwertycoatl: Dec 31, 2008

Another reason to commit often is that if you make some changes that don't work out, it's really easy to get back to where you were before you started, without losing any actual correct work.

# ? Sep 9, 2013 18:58

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

Qwertycoatl posted:

Another reason to commit often is that if you make some changes that don't work out, it's really easy to get back to where you were before you started, without losing any actual correct work.

Which instills a more experimental attitude. I know I'm a lot happier making a bunch of quick fragile changes to test out a concept if I can just quickly revert them without having to go through and manually back them out.

# ? Sep 9, 2013 19:04

Lurchington: Jan 2, 2003; Forums Dragoon

dammit javascript and/or V8's implementation of javascript :mad:

code:

> 'str' ++ 'asdasd '
SyntaxError: Unexpected string
> 'str' + + 'asdasd '
"strNaN"

https://github.com/jacobangel/lambic/commit/c0b51c16a04ff080774ecb885a50c32bbf552ffd#commitcomment-4039686

# ? Sep 9, 2013 19:25

seiken: Feb 7, 2005; hah ha ha

Lurchington posted:

dammit javascript and/or V8's implementation of javascript
code:
> 'str' ++ 'asdasd '
SyntaxError: Unexpected string
> 'str' + + 'asdasd '
"strNaN"
https://github.com/jacobangel/lambic/commit/c0b51c16a04ff080774ecb885a50c32bbf552ffd#commitcomment-4039686

I'm not sure why you'd find either of these surprising.

Edit: I mean it's bad as far as loose typing and implicit coercions are bad wherever they pop up, but the parsing stuff is pretty much sensible (same thing happens in most languages, also with - and --)

seiken fucked around with this message at 20:00 on Sep 9, 2013

# ? Sep 9, 2013 19:57

Dr Monkeysee: Oct 11, 2002; just a fox like a hundred thousand others; Nap Ghost

Munkeymon posted:

The last time I used SourceTree, I think it outright told me to drop to the command line to do something or the other.

IDK why but the first thing that popped into my head after reading that was

All of these hashes will be lost, like tears in rain. Time to git push origin master --force.

# ? Sep 9, 2013 20:22

Pilsner: Nov 23, 2002

Rocko Bonaparte posted:

It may be my own misadventures with TFS was poor, but I always had a hard time finding when a particular change happened and what happened with it. How do you do it?

Perhaps another reason in TFS to minimize changes is to reduce how many different files you have checked out in some fashion. That kind of assumes you have those jackasses that lock everything when they edit.

Easy, right-click a branch or directory, View History, hope there's a good checkin message and that the checkin was an atomic, small change. Same as any other system to be honest. However, I admit I don't do it this way, neither writing good messages nor checking in in small clumps. I estimate I have to "dig" for a certain change maybe 5-10 times per year, but the amount of time I spend doing that is far less than what it would take to do "proper" checkins.

We also don't work with that constant merge thing like it seems some do, maybe that's the big difference. We branch once in the beginning of a release cycle (5-6 months, yes that's too long, another topic), which is then the dev branch for the coming release. Work work work on that branch 'til the evening of the release day of course. Any hotfixes along the way are done in the previous branch (production), then merged into dev ad-hoc. When the release rolls around, we branch and start over.

Again, I don't see a problem with doing checkins the strict way, I just don't think it's worth the effort for me, nor do any of my colleagues ever miss it. I'm all for reacting to smells and annoyances, but there just aren't really any in our company with regards to source control, in spite of the old fashioned way we do things.

# ? Sep 9, 2013 20:28

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Seconding Pilsner's experience at my company. We always try to identify the parts in our process that are causing us problems, but the lack of small meaningful commits isn't one of them.

# ? Sep 9, 2013 21:05

..btt: Mar 26, 2008

Pilsner posted:

We also don't work with that constant merge thing like it seems some do, maybe that's the big difference. We branch once in the beginning of a release cycle (5-6 months, yes that's too long, another topic), which is then the dev branch for the coming release. Work work work on that branch 'til the evening of the release day of course. Any hotfixes along the way are done in the previous branch (production), then merged into dev ad-hoc. When the release rolls around, we branch and start over.

I think the point of the constant merge thing is so that you rarely have to do huge merge operations which can be error prone even with the best tools in the world. When the changes are very small, it's a lot less likely to cause huge conflicts, and since you do it frequently, the changes are likely to be fresh in your mind when you do it. Then as other people have mentioned, your history and changesets tend to be a lot cleaner and easier to digest, which means you're more likely to actually use it to locate weird new issues rather than just muddle through the current latest version of the codebase.

Honestly, I just find decentralised VCS are a much more pleasant experience than the old-style, and give you a lot more power to structure your own work, even when not working on a team. When I used to do personal projects, I'd never have bothered with source control as anything but a backup. These days the first thing I do, even for something trivial, is "hg init". I can appreciate why they might seem onerous and pointless until you can get used to this way of working though.

I'm probably also biased against TFS though, or for that matter big, complicated, monolithic systems on the whole.

# ? Sep 9, 2013 21:28

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

You may or may not benefit from smaller commits, but "we've never missed them" isn't a good reason to not use them.

There's all sorts of things in this world where the benefits aren't apparent until you've used them.

Like, for example, maybe they wouldn't do anything for you if naively dropped into your current processes, but would greatly improve your productivity when used in processes designed for them.

# ? Sep 9, 2013 21:35

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

For those who don't appreciate small commits, I encourage you to view our legacy codebase, where a certain developer would save all of his changes for the week until Friday evening, where he would make one large commit with an enlightening message like "fixed".

This legacy is basically where your argument is coming from.

# ? Sep 9, 2013 23:00

JawnV6: Jul 4, 2004; So hot ...

Pilsner posted:

Again, I don't see a problem with doing checkins the strict way, I just don't think it's worth the effort for me, nor do any of my colleagues ever miss it. I'm all for reacting to smells and annoyances, but there just aren't really any in our company with regards to source control, in spite of the old fashioned way we do things.

It's really weird to see this all phrased in terms of "effort" because jfc you typed out 20 commit's worth of messages defending doing it the lovely way, which you weren't presumably paid to do. Nobody's sitting there at the machine limit of efficiency. We're all somewhere at the 5-10% mark in terms of how much code could actually be wrung out of us. Typing two sentences about your state of mind once a feature is zero effort amortized across a project.

If you're just using version control to make safe checkpoints once a day, no poo poo you never look back at them. You don't have a reason to since they're worthless apart from giant fuckoff failures. You're also not, as Desert Rose pointed out, doing small one-off experimental builds with the confidence that you can back it all out quickly.

# ? Sep 9, 2013 23:55

nielsm: Jun 1, 2009

JawnV6 posted:

We're all somewhere at the 5-10% mark in terms of how much code could actually be wrung out of us. Typing two sentences about your state of mind once a feature is zero effort amortized across a project.

To chime in on this point, spending a couple minutes considering how my changes relate and writing a sensible message let's me better understand what I've been doing, and might let me catch little stupid things before they become big.
The best thing using git has given me is GUI clients with an easy way to cut a larger unstated change set into several smaller commits. I suppose it's like doing a code review of your own work. Try it, it actually feels good.

# ? Sep 10, 2013 00:05

Superschaf: May 20, 2010

nielsm posted:

To chime in on this point, spending a couple minutes considering how my changes relate and writing a sensible message let's me better understand what I've been doing, and might let me catch little stupid things before they become big.

This is a really important part. Writing out the What and (more importantly) the Why, forces you to sanity-check your own changes. That helped me a lot to improve as a programmer.
Also as I write out the Why I often notice "Oh poo poo this isn't really as obvious as I thought" and add some more comments.

# ? Sep 10, 2013 00:20

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 16:25

Lurchington: Jan 2, 2003; Forums Dragoon

seiken posted:

I'm not sure why you'd find either of these surprising.

Edit: I mean it's bad as far as loose typing and implicit coercions are bad wherever they pop up, but the parsing stuff is pretty much sensible (same thing happens in most languages, also with - and --)

I find it surprising that JavaScript has a syntax error for 'butts' ++ 'dongs', and has a coercion in 'butts' + + 'dongs'
I found it especially surprising that this was the root cause of this weird extra text in my rendered web page

Perhaps everyone else in the world is an expert at this js eccentricity, but I personally would have expected a syntax error for both of those things.

# ? Sep 10, 2013 00:32

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 »