Programming thread

Rango Dango said:
I am consistent
variables - snake_case
functions - camelCase
types - PascalCase
#define/constexpr/enum constants - SCREAMING_CASE
files - no case at all fuck you
it basically allows you to differentiate things at a glance like syntax highlihgting, except symbols instead of colors
Click to expand...
Fuck it. I'm just gonna say it. I use Hungarian notation in my c code, I understand the issue with it in c++ because nested generic bs becomes impossible to represent a quick prefix but I fail to see why "Hungarian notation bad"
has become the general consensus. I use it in my local vars only because I will often get naming collisions with the function arguments.
 
Blorgus said:
Fuck it. I'm just gonna say it. I use Hungarian notation in my c code, I understand the issue with it in c++ because nested generic bs becomes impossible to represent a quick prefix but I fail to see why "Hungarian notation bad"
has become the general consensus. I use it in my local vars only because I will often get naming collisions with the function arguments.
Click to expand...
because theres no reason, especially since there's no auto in c
i have clangd to tell me if its the wrong type, if i dont use it, i have the compiler itself sperging out over me trying to add an int to a const char* or whatever the fuck
 
moocow said:
It looks like ass and is an unreliable crutch to try to enforce strict typing via convention in languages that already do so via compilation errors.
Click to expand...
It's for readability. Sometimes you're dealing with different data structures, like a product id list and a product id set. If they're one-purpose things, you might call the latter "product_id_distinct_seen_cache" or something, but what if not? Just write "_set".

It makes more sense to use Hungarian notation in strictly typed code (because once you type it, no one can subvert it, you see a _set variable and immediately know it is indeed a set) than in the likes of Python where a _set can turn out to be fake and gay.
 
  • Disagree
Reactions: Concentrate Juice
Blorgus said:
Fuck it. I'm just gonna say it. I use Hungarian notation in my c code, I understand the issue with it in c++ because nested generic bs becomes impossible to represent a quick prefix but I fail to see why "Hungarian notation bad"
has become the general consensus. I use it in my local vars only because I will often get naming collisions with the function arguments.
Click to expand...
The original point of Hungarian notation was to encode things that the type system couldn't encode, so you'd e.g. use iThings for an index and nThings for a count even though both are ints. When Microsoft adopted it, they did so in the most retarded way possible by only repeating what the type already encoded.
 
  • Like
Reactions: Rusty Metal Skull Gun, Verpa Teutonica Ingens, ADHD Mate and 3 others
306h4Ge5eJUJ said:
The original point of Hungarian notation was to encode things that the type system couldn't encode, so you'd e.g. use iThings for an index and nThings for a count even though both are ints. When Microsoft adopted it, they did so in the most retarded way possible by only repeating what the type already encoded.
Click to expand...
the funny thing is that it was invented in microsoft and then microsoft completely fucked up their own convention
 
  • Horrifying
  • Like
Reactions: Rusty Metal Skull Gun and 306h4Ge5eJUJ
Thing is, you guys work with nice c compilers like clang and GCC. MSVC historically has been (and still is) not great. I find it much better to rely on a prefix esp. For diagnosing things like signedness conversion wackiness or even some very strange implicit conversions that msvc decides are acceptable (Schroedinger's pointer)

There are times where additional metadata cannot be solved in the type system too.

There have been times where I may take multiple forms of a string, one null terminated and one in the form of a struct with a buffer and length field and it's been nice to visually be able to tell each type from each other.

Same with ANSI vs UTF8 and to a lesser extent UNICODE vs UTF8.

Also there have been times where endianess has mattered or I'm using a special pointer to struct which is opaque, you'll be wanting to encode additional information in the name there.
 
I don't think about case at all.
spunk.jpg
 
  • Winner
Reactions: Geddy Lee's Fee and See
fr just make all your variables 1 uppercase letter (maybe even 2)
first one you put in should be A and next is B etc
ez
 
  • Like
Reactions: Lard Shart and Horpach
Verpa Teutonica Ingens said:
I'm pretty sure he's referring to desktop software, not webapp shitware. Users of desktop programs merely need to snoop around their own machines, not the developer's machines, to find things like the app tokens that are needed for OAuth2.

I'm sure there's some authentication flow to accommodate desktop programs, as a generous consolation from our benevolent Google benefactors. I'm also sure that it's needlessly complicated, on a similar level as Java enterprise jeetware.
Click to expand...
I wish you were right, but the docs don't say anything about the handshake not needing the secret, even for desktop apps.

refreshing access token requires client secret keep secure.webp
refreshing access token requires client secret oauth handshake.webp
 
  • Horrifying
Reactions: 306h4Ge5eJUJ, nah and Verpa Teutonica Ingens
Can someone explain Monads in a non-retarded way?

From what I understand they're a wrapper type that bind themselves to a value type with a bind function, and then produce a side effect with a run function, which itself wraps around an inner function call, for which the wrapped value is substituted as the function argument.

Am I on the right track or am I retarded?
 
That would be IO monad. In general monad is any type for which exists associative(specific order of evaluation doesn’t matter) function of type monad->monad->monad called bind, identity element ie element that when combined with any value doesn’t change it’s value and type constructor a —function that takes type and returns monadic type.
 
Last edited:
You must log in or register to reply here.
Back