this post was submitted on 09 May 2024
12 points (92.9% liked)

Programmer Humor

32571 readers
455 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
top 41 comments
sorted by: hot top controversial new old
[–] algernon@lemmy.ml 7 points 6 months ago (3 children)

Sadly, that's not code Linus wrote. Nor one he merged. (It's from git, copied from rsync, committed by Junio)

[–] riodoro1@lemmy.world 4 points 6 months ago

You really think someone would do that? Just go on the internet and tell lies?

[–] ngn@lemy.lol 3 points 6 months ago (4 children)
[–] Epzillon@lemmy.ml 5 points 6 months ago (1 children)

Isn't that from 1991 while the quote is from 1995? If we're nitpicking maybe we shouldn't time travel 🤓

[–] lowleveldata@programming.dev 3 points 6 months ago (1 children)

Damn it Time Patrol! You can't stop me!

[–] avidamoeba@lemmy.ca 2 points 6 months ago
[–] metallic_z3r0@infosec.pub 5 points 6 months ago

I mean it was 0.01, at that point he was screwed anyway, and he fixed his program.

[–] redcalcium@lemmy.institute 4 points 6 months ago (1 children)

He wouldn't make that statement unless he experienced the horror himself.

Now, if he still does it these days...

[–] rwhitisissle@lemmy.ml 2 points 6 months ago

I've heard similar from the worst first year CS students you could ever meet. People talk out their ass without the experience to back up their observations constantly. The indentation thing is a reasonable heuristic that states you are adding too much complexity at specific points in your code that suggests you should isolate core pieces of logic into discrete functions. And while that's broadly reasonable, this often has the downside of you producing code that has a lot of very small, very specific functions that are only ever invoked by other very small, very specific functions. It doesn't make your code easier to read or understand and it arguably leads to scenarios in which your code becomes very disorganized and needlessly opaque purely because you didn't want additional indentation in order to meet some kind of arbitrary formatting guideline you set for yourself. This is something that happens in any language but some languages are more susceptible to it than others. PEP8's line length limit is treated like biblical edict by your more insufferable python developers.

[–] refalo@programming.dev 1 points 6 months ago

line 152 is the only thing past 3 levels and I'd say that one gets a pass.

[–] laughterlaughter@lemmy.world 1 points 6 months ago

Plus it shows three levels of indentation. Well... there is the extra one created by the compiler directives, but do they really count?

[–] reverendsteveii@lemm.ee 6 points 6 months ago

rules aren't there to be enforced, they're there so that when you break them you take a second to think about why.

[–] Kimano@lemmy.world 1 points 6 months ago

My personal code readability axe to grind is nested complex ternary operators.

Every now and then I'll see something like this

return (checkFormatType(currentObject.type==TYPES.static||currentObject type==TYPES.dynamic?TYPES.mutable:TYPES.immutable)?create format("MUTABLE"):getFormat(currentObject));

And I have a fucking conniption because just move that shit into a variable before the return. I get it when sometimes you just need to resolve something inline, but a huge amount of the time that ternary can be extracted to a variable before the ternary, or just rewrite the function to take multiple types and resolve it in the function.

[–] Tolookah@discuss.tchncs.de 1 points 6 months ago (3 children)

I didn't know why, but *++p bugs me

[–] lseif@sopuli.xyz 1 points 6 months ago

welcome to C

[–] marcos@lemmy.world 0 points 6 months ago* (last edited 6 months ago) (1 children)

That *++ operator from C is indeed confusing.

Reminds me of the goes-to operator: --> that you can use as:

while(i --> 0) {
[–] letsgo@lemm.ee 1 points 6 months ago

That's not a real operator. You've put a space in "i--" and removed the space in "-- >". The statement is "while i-- is greater than zero". Inventing an unnecessary "goes to" operator just confuses beginners and adds something else to think about while debugging.

And yes I have seen beginners try to use <-- and --<. Just stop it.

[–] Tyoda@lemm.ee 0 points 6 months ago* (last edited 6 months ago) (2 children)

Perhaps *(p += 1) will be to your liking?

[–] fluckx@lemmy.world 0 points 6 months ago* (last edited 6 months ago) (1 children)
p = 1

x = ++p
// x = 2
// p = 2
p = 1
x  = p++
// x = 1
// p = 2

++p will increase the value and return the new value

p++ will increase the value and return the old value

I think p = p + 1 is the same as p++ and not as ++p. No?

[–] SpaceNoodle@lemmy.world 0 points 6 months ago* (last edited 6 months ago) (1 children)

(p += 1) resolves to the value of p after the incrementation, as does ( p = p + 1).

[–] fluckx@lemmy.world 0 points 6 months ago (1 children)

Yes.

p++ == p+= 1 == p = p + 1 are all the same if you use it in an assignment.

++p is different if you use it in an assignment. If it's in its own line it won't make much difference.

That's the point I was trying to make.

[–] SpaceNoodle@lemmy.world 1 points 6 months ago

No.

++p returns incremented p.

p += 1 returns incremented p.

p = p + 1 returns incremented p.

p++ returns p before it is incremented.

[–] xmunk@sh.itjust.works -1 points 6 months ago (1 children)

Much better... but can we make it *((void*)(p = p + 1))?

[–] shrugal@lemm.ee -1 points 6 months ago

How about some JavaScript p+=[]**[]?

[–] Juice@midwest.social 1 points 6 months ago

Broad generalizations aren't for the people who make them, they're for the suckers who consistently fall for them

[–] RedditWanderer@lemmy.world 1 points 6 months ago (1 children)

Only the sith deal in absolutes

[–] Entropywins@lemmy.world 1 points 6 months ago (1 children)
[–] 69420@lemmy.world 1 points 6 months ago

Absolutely.

[–] dejected_warp_core@lemmy.world 0 points 6 months ago (1 children)

One nit: whatever IDE is displaying single-character surrogates for == and != needs to stop. In a world where one could literally type those Unicode symbols in, and break a build, I think everyone is better off seeing the actual syntax.

[–] PlexSheep@infosec.pub 1 points 6 months ago

I think it's a lineature. FiraCide does that for example, and I like it very much. My compiler and lsp will tell me if there is a bad char there. Besides, the linea tires take the same space as two regular characters, so you can tell the difference.

It's not the 90s anymore. My editor can look nice.

[–] ZILtoid1991@lemmy.world 0 points 6 months ago (1 children)

Why is multiple levels of indentation bad?

IDK, but if the reason is "to break stuff into multiple functions", then I'm not necessarily writing yet another single-use function just to avoid writing a comment, especially in time critical applications. Did that with a text parser that could get text formatting from a specifically written XML file, but mainly due to it being way less time critical, and had a lot of reused code via templates.

[–] theherk@lemmy.world 1 points 6 months ago

Like with everything, context matters. Sometimes it can indicate poorly structured control flow, other times inefficient loop nesting. But many times it is just somebody’s preference for guard clauses. As long as the intent is clear, there are no efficiency problems, and it is possible to reach the fewest branches necessary, I see no issues.

[–] RustyNova@lemmy.world 0 points 6 months ago* (last edited 6 months ago) (1 children)

While I totally agree with that philosophy, it heavily depends on the language.

For Rust, my philosophy is more like this:

  • Impl + fn body don't count, as well as async blocks if they span the whole function
  • do not nest more than one if statement. You probably better using guard clauses or matches
  • do not put loops into an if statement.
  • do not nest loops unless clearly shown to be (X, Y) indexing
  • method chaining is free
  • do not nest closures, unless the nested closure doesn't have a {} block
  • do not use mod unless it's test for the current module. No I don't want to Star Wars scroll your 1000 line file. Split it.
[–] calcopiritus@lemmy.world 0 points 6 months ago (1 children)

Why have an async block spanning the whole function when you can mark the function as async? That's 1 less level of indentation. Also, this quite is unusable for rust. A single match statement inside a function inside an impl is already 4 levels of indentation.

[–] Doods@infosec.pub -1 points 6 months ago (3 children)

A single match statement inside a function inside an impl is already 4 levels of indentation.

How about this?

The preferred way to ease multiple indentation levels in a switch statement is to align the switch and its subordinate case labels in the same column instead of double-indenting the case labels. E.g.:

switch (suffix) {
case 'G':
case 'g':
        mem <<= 30;
        break;
case 'M':
case 'm':
        mem <<= 20;
        break;
case 'K':
case 'k':
        mem <<= 10;
        /* fall through */
default:
        break;
}

I had some luck applying this to match statements. My example:


let x = 5;

match x {
5 => foo(),
3 => bar(),
1 => match baz(x) {
	Ok(_) => foo2(),
	Err(e) => match maybe(e) {
		Ok(_) => bar2(),
		_ => panic!(),
		}
	}
_ => panic!(),
}

Is this acceptable, at least compared to the original switch statement idea?

[–] RustyNova@lemmy.world 0 points 6 months ago (1 children)

It's a lot less readable imo. As well than a cargo fmt later and it's gone (unless there's a nightly setting for it)

[–] Doods@infosec.pub -1 points 6 months ago

Formatters are off-topic for this, styles come first, formatters are developed later.

My other reply:

How about this one? it more closely mirrors the switch example:

match suffix {
'G' | 'g' => mem -= 30,
'M' | 'm' => mem -= 20,
'K' | 'k' => mem -= 10,
_ => {},
}

How about this other one? it goes as far as cloning the switch example's indentation:

match suffix {
'G' | 'g' => {
  mem -= 30;
       }
'M' | 'm' => {
  mem -= 20;
       }
'K' | 'k' => {
  mem -= 10;
       }
_ => {},
}
[–] calcopiritus@lemmy.world 0 points 6 months ago (1 children)

Well, of course you can have few indent levels by just not indenting, I don't think the readability loss is worth it though. If I had give up some indentation, I'd probably not indent the impl {} blocks.

[–] Doods@infosec.pub -1 points 6 months ago* (last edited 6 months ago)

I just got some idea yesterday regarding impl blocks, ready to be my respondent?

I had a big impl block with 4 levels of indentation, so I cut the block, and replaced

impl InputList {
    //snip
}

with mod impl_inputlist; and moved the impl block to a new file, and did not indent anything inside that block.

The advantage this has over just not indenting the impl block in place, is that people will have difficulty distinguishing between what's in the block and what's outside, and that's why the impl was moved to its own exclusive file, impl_inputlist.rs

Maybe I am overstressing indentation. Ss there something wrong with my setup that prevents me from accepting 4-space indentation?

I use:

Editor: Neovide

Font: "FiraCode Nerd Font Mono:h16" (16px fonts are addicintg)

Monitor: 1366x768, 18.5 inch, 10+ years old, frankenstein-ly repaired Samsung monitor.

Distance: I sit at about 40-60 Cm from my monitor.

That leaves me with a 32x99 view of code excluding line numbers and such.

[–] lseif@sopuli.xyz 0 points 6 months ago (1 children)

i personally find this a lot less readable than the switch example. the case keywords at the start of the line quickly signify its meaning, unlike with => after the pattern. though i dont speak for everybody.

[–] Doods@infosec.pub -1 points 6 months ago* (last edited 6 months ago)

How about this one? it more closely mirrors the switch example:

match suffix {
'G' | 'g' => mem -= 30,
'M' | 'm' => mem -= 20,
'K' | 'k' => mem -= 10,
_ => {},
}

How about this other one? it goes as far as cloning the switch example's indentation:

match suffix {
'G' | 'g' => {
	mem -= 30;
        }
'M' | 'm' => {
	mem -= 20;
        }
'K' | 'k' => {
	mem -= 10;
        }
_ => {},
}