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!

«‹›20 »

QuarkJets: Sep 8, 2008

ExcessBLarg! posted:

This is a problem that's faced by every dictionary/map API ever. The options are generally:

Return null when a key does not exist, which may create ambiguity with keys explicitly assigned null (if that's actually possible, and if the distinction is relevant).

Allow the code to supply a default value to return if the key is not present (usually as an argument) and return that value.

Return an optional type, if the language supports optional types and if they were supported at the time the map/dictionary API was drafted.

Throw an exception.
Of these, throwing an exception is my personal least favorite. I'm a believer that "exceptions should be used for exceptional situations" and a key-not-present condition is usually a frequent occurrence. In practice though, it depends on how exception handling is implemented in the runtime and if thrown exceptions aren't heavyweight in terms of performance cost, then whatever. Also, some languages like Python utilize exceptions as part of standard control flow (e.g., raising a StopIteration exception is expected as part of the iterator protocol).

I like the Python implementation of having 2 different ways to fetch something from a dict: one that raises an exception if the key isn't present, and one that returns a default value. They're both good approaches, sometimes I want the first one, sometimes I want the second.

# ¿ Dec 12, 2023 00:20

Adbot: ADBOT LOVES YOU

# ¿ May 21, 2024 02:36

QuarkJets: Sep 8, 2008

deliberately writing bad code and then getting salty at visual studio for just say "nah"

# ¿ Dec 18, 2023 04:54

QuarkJets: Sep 8, 2008

Falcon2001 posted:

So, one of the juniors on my team came up with something I said (in a code review) was "beautiful and terrible".

Minor vagueness in backstory: so we have a service (written in Python) that operates on a list of objects; the objects are in a strict hierarchy and the names are expressed as ParentObj/ChildObj/ChildOfChildObj, etc etc. We identified a bug in some code where there was an inheritance of an attribute from parent to child that this program was trying to change; so changing the parent and then trying to change the child would result in an error, since you were trying to add something to a set that already existed, essentially.

Example:
code:
# Denotes an object with a parent
# Blue/Apple/One 
  Blue/Banana/One
# Blue/Apple/Two
  Blue/Apple
# Red/Banana/One
  Red
# Red/Banana
Of that list, we only need to modify three, as those are the ones without parents. This sounds like an interview question: it's a reasonably straightforward logical application of low level algorithms. There's a ton of ways to solve it, and my junior was really struggling, so I walked them through a few options, mostly involving utilizing str.split('/') and then doing simple list interpretation. I assumed this wouldn't be a big problem and didn't want to get too directive about it, so I left it open ended.

The PR I received contained the phrase "I have used PurePath in my implementation, confirmation of logic in ticket". I kind of blew past that at first, and then had to go back and read it again.

"Wait...PurePath? Did I read that right?" I then opened the PR and confirmed that yes, I had read that right.

The way they solve this was to interpret each object name as a Unix-style file path using Python's stdlib Pathlib module, and then utilize directory crawling patterns to achieve the answer. I was immediately horrified, followed almost directly afterward by 'wait...hold on. Does this...work?' and I looked into it.

So a minor note aside that PurePosixPath was a better option to ensure that the OS didn't freak out, I came to the conclusion that this...definitely worked. Now, the rest of their implementation was pretty weird, involving some significant logic issues, but here's the final implementation, give or take:
Python code:
def find_parents(obj_list: List[Object]) -> List[Object]
    path_parents = [PurePosixPath(obj.name) for obj in obj_list]
    return [str(obj) for obj in path_parents if any(y in obj.parents for y in path_parents)]
These objects maintain very similar naming requirements to PosixPaths, and in fact are more strict - strictly alphabetical, no weird runes or emojis/etc, no spaces or punctuation at all. As far as we can tell, valid object names are a subset of all valid file path names, so this...works. The code is quite readable, and the underlying implementation can be generally assumed to be well tested as part of the standard library. Aside from refactoring a weird recursive lookup they had implemented, my only other comment was that they absolutely had to leave a clear comment about how we're not actually handling file paths.

Now, could we have written something else? Sure, and it probably would have been just as readable, but I was kind of awestruck at this hacky thing, and it was reasonably constrained so...I approved it.

Given the choice between easy to read and comprehend vs clever I prefer the former, but if it's well-tested then clever is fine

# ¿ Feb 8, 2024 23:56

QuarkJets: Sep 8, 2008

Jen heir rick posted:

That's a lot of useless comments. Be nice if it said what the type is for and how it's used.

You don't get it, only an AI is capable of writing so many white-noise comments

# ¿ Mar 6, 2024 21:34

QuarkJets: Sep 8, 2008

repiv posted:

https://twitter.com/dankuntz/status/1765445935407235252

lmao this one is great

# ¿ Mar 7, 2024 20:07

QuarkJets: Sep 8, 2008

Python code:

def is_even(x):
    raise NotImplementedError()

# ¿ Mar 11, 2024 07:18

QuarkJets: Sep 8, 2008

Volguus posted:

If the alternative was python or electron on the desktop, gently caress yeah, Java is a million times more preferable to those abominations. If it was to be in a browser anyway, suggesting Java (as an applet? Web start?) that's is indeed a capital sin.

Native Python sure, TKinter sucks, but Python also has extremely good support for Qt and Qt is still a gold standard in desktop gui design, so that'd be a reasonably good choice.

I can't think of a good reason to use Java for any kind of frontend at all

# ¿ Mar 24, 2024 22:37

QuarkJets: Sep 8, 2008

Soricidus posted:

Put it this way … if you’re writing python today, most likely you’re writing it either in vscode (electron) or pycharm (java).

I think the desktop apps I use regularly (ignoring the browser itself and stuff built into the os) are a pretty even split between electron, java, and native qt. I don’t think any of them are written in python.

Regardless of how 2 IDE applications happened to be written, Qt is even easier to use in Python than in C++

# ¿ Mar 25, 2024 16:01

QuarkJets: Sep 8, 2008

Rooting around in a dumpster like a filthy DBA

# ¿ Apr 3, 2024 17:12

QuarkJets: Sep 8, 2008

Foxfire_ posted:

I don't think I hate this that much? it's icky, but it's also plain what it does and how it works.

(I do hate that resume() returns 0 on both the first iteration and after it's finished)

The post of a broken man

# ¿ Apr 10, 2024 02:40

QuarkJets: Sep 8, 2008

Floating point arithmetic is magic

# ¿ Apr 29, 2024 01:16

QuarkJets: Sep 8, 2008

Comment rot would be relevant here, there have been plenty of times that I've seen an elaborate set of lines commenting on how some tricky bit of code works and been like "uhh this doesn't work that way at all", then checked the git blame and found out that the comment was written 17 revisions ago

# ¿ Apr 29, 2024 03:38

QuarkJets: Sep 8, 2008

RPATDO_LAMD posted:

Cmake is designed to find dependencies by "magic" through functions like find_package, which basically end up looking for a hand rolled script for each package or else searching in a few standard folders like /usr/lib etc
Getting that poo poo to work on windows which has no standard folder structure anywhere for libs, includes, etc is a pain in the rear end, and because of all the "magic" involved specifying the folder locations explicitly ends up being more verbose and much less obvious than it would've been with a dumb non-magical build system like a plain makefile. And yes the documentation is really poo poo for this with a lot of super general detail on how the various functions work and no simple hello-world examples for "holy poo poo I just wanna link to a library it's RIGHT THERE please just show me three lines of code/config that will do this"

it seems like a pretty good system as long as you (a) never touch windows and (b) never have to actually write the drat cmake files yourself

If you're compiling on Windows then you're probably using Visual Studio or VS Code, which both have CMake extensions that you're supposed to be using to tell cmake where your dependencies live. Then stuff like find_package just works, because you've given it a standard folder structure for things like libs, includes, etc. that us linux developers get to take for granted (although not always, which is why cmake also supports non-standard paths)

# ¿ Apr 29, 2024 08:15

QuarkJets: Sep 8, 2008

Clanpot Shake posted:

Default parameters in Python might qualify? It's more "surprising" than "magical," but it trips people up.

Maybe, yeah. I don't know anyone who uses Python who understood the mutable default argument problem the first time that they encountered it, the behavior is not intuitive.

# ¿ Apr 30, 2024 02:21

Adbot: ADBOT LOVES YOU

# ¿ May 21, 2024 02:36

QuarkJets: Sep 8, 2008

leper khan posted:

better to have a policy of not searching patents. avoids 3x damages

The legal term should be Critical Hit damages

# ¿ May 11, 2024 01:23

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!

«‹›20 »