awful programming: feature flags and suffering

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1115 »

Dont Touch ME: Apr 1, 2018

Bloody posted:

okay now back to git subtrees please

So what was wrong with submodules?

# ? May 19, 2021 05:37

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 16:36

psiox: Oct 15, 2001; Babylon 5 Street Team

when i tried to use git subtrees it was more of a pain than just using submodules- so i just hid that it was submodules from people with a good makefile/whatever tooling

# ? May 19, 2021 05:41

psiox: Oct 15, 2001; Babylon 5 Street Team

imo git submodules are a known quantity of weird and the alternatives are worse

# ? May 19, 2021 05:42

psiox: Oct 15, 2001; Babylon 5 Street Team

comedy option just keep all your deps in the same repo as different refs

https://git-scm.com/docs/git-worktree

# ? May 19, 2021 05:46

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

make way for git subtrac

https://github.com/apenwarr/git-subtrac

# ? May 19, 2021 06:28

CPColin: Sep 9, 2003; Big ol' smile.

I sleep in a big monorepo with my wife

# ? May 19, 2021 07:19

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

is there any forking involved?

# ? May 19, 2021 07:23

Ocean of Milk: Jun 25, 2018; oh yeah

duz posted:

https://twitter.com/gottapatchemall/status/1334628520165658631

Programmers really need to stop abbreviating random words in unconventional ambigous ways. Like, leg_hands is harder to read than legend_handles anyway, just leave it the gently caress alone, goddamnit!

# ? May 19, 2021 07:35

jesus WEP: Oct 17, 2004

Ocean of Milk posted:

Programmers really need to stop abbreviating random words in unconventional ambigous ways. Like, leg_hands is harder to read than legend_handles anyway, just leave it the gently caress alone, goddamnit!

used to work in a financial domain where a lot of fields were like �cumulative amount� or �cumulative quantity�, so agreed

# ? May 19, 2021 08:06

N.Z.'s Champion: Jun 8, 2003; Yam Slacker

Ocean of Milk posted:

Programmers really need to stop abbreviating random words in unconventional ambigous ways. Like, leg_hands is harder to read than legend_handles anyway, just leave it the gently caress alone, goddamnit!

only the first 6 chars of a variable matter to my compiler from 1980 so now you all must suffer

# ? May 19, 2021 10:32

N.Z.'s Champion: Jun 8, 2003; Yam Slacker

even programmers who use actual dictionary word variable names will still cargo cult generics w/ single letters

# ? May 19, 2021 10:41

Soricidus: Oct 21, 2010; freedom-hating statist shill

N.Z.'s Champion posted:

even programmers who use actual dictionary word variable names will still cargo cult generics w/ single letters

you can write List<TheTypeOfThingThatIsInTheList> if you like but everyone else is capable of learning what T means

# ? May 19, 2021 11:11

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

Soricidus posted:

you can write List<TheTypeOfThingThatIsInTheList> if you like but everyone else is capable of learning what T means

I actually hate using T or whatever for this it's unnecessarily unclear imho

method names is my other main hate though. like GetTheNameOfTheThingByTheIdOfTheThing(int id) or similar. just give it a shorter name like GetThingName and put a summary block on it ffs

# ? May 19, 2021 11:26

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

imo when it's one type parameter like "this is the thing the collection contains" then it's fine

if there's two like a map from keys to values then it could go either way really, K,V is pretty clear but KeyType,ValueType wouldn't be too bad either

if you have more than that like AbstractOrganizerStrategy<T,U,V,W> then gently caress right off, give them proper names or get out of my codebase

# ? May 19, 2021 11:51

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Powerful Two-Hander posted:

I actually hate using T or whatever for this it's unnecessarily unclear imho

method names is my other main hate though. like GetTheNameOfTheThingByTheIdOfTheThing(int id) or similar. just give it a shorter name like GetThingName and put a summary block on it ffs

here's a bike for y'all to shed:

assume your language supports method overloading and dynamic dispatch. which of these two styles do you go with:

1)

code:

getThing(id : uuid) : Thing { .. }
getThing(name : string) : Thing? { .. }
getThing(reference: OtherThingThatHoldsIndirectReferenceToAThing) : Thing { .. }
getThing(searchTerms: string []) : Thing? { .. }

code:

getThingById(id : uuid) : Thing { .. }
tryGetThingByName(name : string) : Thing? { .. }
getThingByOtherClassReference(reference: OtherClassThatHoldsIndirectReferenceToAThing) : Thing { .. }
tryGetThingByBestMatch(searchTerms: string []) : Thing? { .. }

# ? May 19, 2021 12:03

jesus WEP: Oct 17, 2004

Soricidus posted:

you can write List<TheTypeOfThingThatIsInTheList> if you like but everyone else is capable of learning what T means

something like IMapper<TInput, TOutput> is a good compromise of descriptive name and the T prefix signalling that it�s the generic type, imo

# ? May 19, 2021 12:08

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

NihilCredo posted:

here's a bike for y'all to shed:

assume your language supports method overloading and dynamic dispatch. which of these two styles do you go with:

1)

code:

getThing(id : uuid) : Thing { .. }
getThing(name : string) : Thing? { .. }
getThing(reference: OtherThingThatHoldsIndirectReferenceToAThing) : Thing { .. }
getThing(searchTerms: string []) : Thing? { .. }

code:

getThingById(id : uuid) : Thing { .. }
tryGetThingByName(name : string) : Thing? { .. }
getThingByOtherClassReference(reference: OtherClassThatHoldsIndirectReferenceToAThing) : Thing { .. }
tryGetThingByBestMatch(searchTerms: string []) : Thing? { .. }

the second thing and i hope to god the first thing doesn't actually compile because the return types are different. if the return types are the same, the first thing probably. unless one of these methods has wildly different efficiency or runtime costs than the others in which case back to the second thing. i'd only use overloads if it's fully a convenience thing and the different argument forms are like a oneliner pointer chase away from each other.

# ? May 19, 2021 12:13

Ocean of Milk: Jun 25, 2018; oh yeah

First thing when I'm calling it and I know it's just gonna work when I feed it whatever because it's been written by someone much smarter than me.
Second thing when I have to actually look at the class in the IDE to understand what it does, let alone change it.

code:

// these are very probably gonna be one-line wrappers anyway
getThing(id : uuid) : Thing { .. }
getThing(otherThing : SomeOtherParamThatWillAlwaysReturnAThing) : Thing { .. }

// same, but with Optional return
tryGetThing(name : string) : Thing? { .. }
tryGetThing(otherThing : SomethingLikeNameThatMayNotFindAnything) : Thing? { .. }

 // A search may return zero, one, or multiple Things
searchThings(params : SearchParams) : ListThatCanBeEmpty<Thing> { .. }

is what I would write.

Things like getThing(directReferenceHolder: OtherThingThatHoldsIndirectReferenceToAThing) shouldn't exist, just do getThing(directReference: ActualMeaningFulReference), cause IDEs are smart enough to suggest getThing(thingWithIndirectReference.getActualMeaningfulReference()) to you.

Pseudo-edit:

quote:

code:

getThing(searchTerms: string []) : Thing? { .. }

code:

tryGetThingByBestMatch(searchTerms: string []) : Thing?

I had to look at this thing in the second List to even notice what the idea was (by best match).

# ? May 19, 2021 13:28

shoeberto: Jun 13, 2020; which way to the MACHINES?

Option 2 generally from a maintenance perspective, especially when you have a well-formed naming schema, ie "getThingBy[concept]", but otherwise try to keep the method names terse to make it not terribly obnoxious to use.

getThingById
getThingByClass
getThingByName
getThingBySearch

Don't put "try" in the names, since exception handling should be delegated to the caller. If your code expects a return and the specific get method doesn't have something, that's an exception. Make sure the get methods throw a specialized typed exception so callers can handle it appropriately.

Regarding abbreviation talk, we have a fairly active policy against them in any form. Find another way to make your variables terse that doesn't involve arbitrarily shaving out letters that are critical for context. Sometimes names need to be long for clarity. That's what IDEs and autocomplete are for. "legend_handle" is completely within reason imo.

Thank you for coming to my ted talk.

# ? May 19, 2021 13:58

Bloody: Mar 3, 2013

Phobeste posted:

the second thing and i hope to god the first thing doesn't actually compile because the return types are different. if the return types are the same, the first thing probably. unless one of these methods has wildly different efficiency or runtime costs than the others in which case back to the second thing. i'd only use overloads if it's fully a convenience thing and the different argument forms are like a oneliner pointer chase away from each other.

lol why wouldn't the first compile?

# ? May 19, 2021 14:07

Powerful Two-Hander: Mar 10, 2004; Mods please change my name to "Tooter Skeleton" TIA.

I don't like the "try" bit either because whenever I've seen it it's been abused to mean "I don't know what I'm actually calling inside this and sometimes it fails and idk why so I'll call it 'try... ' and make the return type nullable", but that's because I see a lot of terrible code (and write it as well)

# ? May 19, 2021 14:08

xtal: Jan 9, 2011; by Fluffdaddy

N.Z.'s Champion posted:

even programmers who use actual dictionary word variable names will still cargo cult generics w/ single letters

It's called math honey

# ? May 19, 2021 14:08

Bloody: Mar 3, 2013

the first is correct. no need to repeat the type of the parameters in the method name, unless you're working in some hellscape like js or python where that isn't immediately obvious to the developer

# ? May 19, 2021 14:08

Bloody: Mar 3, 2013

trygetthing is useful when set presence and value are both being determined at once, like in a dictionary. being given a return value alone is not sufficient without also signaling success in some manner, either by wrapping the T of the dictionary in a Result or by returning a (bool, T) by some means

# ? May 19, 2021 14:11

Forums Medic: Oct 2, 2010; i be out there in orbit

Shaggar posted:

here's a bike for y'all to shred:

# ? May 19, 2021 14:14

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

Bloody posted:

lol why wouldn't the first compile?

oh i guess it does yeah. it's kind of gross to me to do that though imo optionals shouldn't be covariant with concrete results

# ? May 19, 2021 14:17

Bloody: Mar 3, 2013

yeah there's an issue there for sure. seems unlikely that get thing is gonna return a thing for every possible uuid but not every possible string

# ? May 19, 2021 14:24

Ocean of Milk: Jun 25, 2018; oh yeah

xtal posted:

It's called math honey

If this is any indication, mathematicians also write at least a few lines of prose (often an entire paragraph) for every line of equations.

# ? May 19, 2021 14:29

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Phobeste posted:

oh i guess it does yeah. it's kind of gross to me to do that though imo optionals shouldn't be covariant with concrete results

the return type is irrelevant, they could return the same type or four completely different types and it wouldn't matter

the reason it compiles is because the _parameter_ types are unambiguously distinct (uuid, string, class, string list), so the parametric polymorphism can be statically checked

# ? May 19, 2021 14:35

jesus WEP: Oct 17, 2004

i only like try in a method name when it�s a tryget pattern like bool TryGetGoodPosts(int userId, out string[] goodPosts). of course that example would always return false

# ? May 19, 2021 14:44

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

NihilCredo posted:

the return type is irrelevant, they could return the same type or four completely different types and it wouldn't matter

the reason it compiles is because the _parameter_ types are unambiguously distinct (uuid, string, class, string list), so the parametric polymorphism can be statically checked

i get that i'm saying it shouldn't work that way because it's gross to have the kind of the return vary. the return varying by type (e.g. float -> float and int -> int) is fine but it's gross, to me, that you can have int -> int and float -> float?.

# ? May 19, 2021 14:46

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

it's fine, op

capitalizing method names, however, is a crime against humanity

# ? May 19, 2021 14:52

Ocean of Milk: Jun 25, 2018; oh yeah

Yeah there's this notion in some OOP texts/systems that methods with different parameters but the same name are somehow "the same", which is bizarre to anyone used to method overloading in statically typed systems. The term "method overloading" itself becomes weird, like why do we even have a special name for the idea that getThing(name : String) and getThing(id: Uuid) are not the same method? There's no inherent connection between the two except you call them with the same name. But that's what arguments are for.

# ? May 19, 2021 14:52

Corla Plankun: May 8, 2007; improve the lives of everyone

they are the same in the sense that anyone reading your code will gloss over the difference at first, and that is the only sameness that actually matters when you're talking about writing code for work that other people or future you will have to read

# ? May 19, 2021 15:07

Bloody: Mar 3, 2013

if they have the same name then the differences should be gloss over able

# ? May 19, 2021 15:11

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Ocean of Milk posted:

Yeah there's this notion in some OOP texts/systems that methods with different parameters but the same name are somehow "the same", which is bizarre to anyone used to method overloading in statically typed systems. The term "method overloading" itself becomes weird, like why do we even have a special name for the idea that getThing(name : String) and getThing(id: Uuid) are not the same method? There's no inherent connection between the two except you call them with the same name. But that's what arguments are for.

the reason they're connected is because oop subtyping can interact with dynamic dispatching in funny ways

code:

class geek
class nerd : geek
class dork : geek

getThing : geek -> thing
getThing : dork -> thing


var g : geek = random() > 0.5 ? new nerd() : new dork()

var thing = getThing(g)

some oop users expect this code to have a 50% chance of calling either overload. THEY HAVE PLAYED US FOR ABSOLUTE FOOLS

# ? May 19, 2021 15:12

12 rats tied together: Sep 7, 2006

modern languages like rust, golang, python, et.c intentionally not supporting overloads is one of the best decisions each of them has made

# ? May 19, 2021 15:15

CPColin: Sep 9, 2003; Big ol' smile.

jesus WEP posted:

used to work in a financial domain where a lot of fields were like “cumulative amount” or “cumulative quantity”, so agreed

My predecessor abbreviated "functional access profile" all over the place.

# ? May 19, 2021 15:30

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

it actually makes total sense for Calculator.Add(float, float) to return a float, while Calculator.Add(int, int) returns an int

# ? May 19, 2021 15:45

Adbot: ADBOT LOVES YOU

# ? Apr 29, 2024 16:36

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

code:

tryGetThingByBestMatch(searchTerms: string []) : Thing?

i'd call this findThing, tryGet sounds more like it'll throw if it doesn't find a Thing

# ? May 19, 2021 15:54

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1115 »