PM is such a fucking cunt
telling me that my data structures describing the layout of binary data would be confusing for devs, and that we shall introduce

typedef fuckingRetardedObfuscatingName uint8_t;

in our code. everyone is fine with the concepts i provide to describe this binary data, not only at our company but also in other software i've worked on and common standards i've worked with, we work like that and every fucking idiot knows what a uin8_t is.

you fucking braindead imbecile have no fucking idea how we work and you don't care, you don't even try to understand what we are doing.
god i hope you die being hit by a fucking bus or something

Understandable. But the death wishes are a bit too much, no need to traumatize the poor bus driver, just have him fall of a cliff or something
Also, fuckingRetardedObfuscatingName is a really bad name for a type. Did you recommend a small intro into clean coding conventions to him?

@CodingPeasant at least it's not a three letter acronym

@PeterDCarter we could make it a 4 letter acronym and just call it "fron"

Oh, I'm glad to hear I'm not the only one defining aliases for literally every use of a datatype.

type Rgba8 = u32;

type Url = &str;

type Base64 = &str;

type ExecutorState = Hashmap<String, Vec<Expression>>;

Eventually, when I want to introduce custom logging or otherwise properly distinguish these from their base type, I can just turn the alias into a type and all valid code remains valid, plus I also instantly get errors about dubious casts.

Crucially, the datatype (or alias) continues to tell me WHAT something is, and the name of the field/local/getter tells me its ROLE. If a concept occurs frequently across multiple names which also share a type, I introduce an alias to capture the common part and adjust the names to represent the specifics.

@lbfalvy i'm not criticizing typedefs in general, PM only made some really terrible suggestions that didn't make any sense, thinking they are the greatest invention everybody needs, and thinking that without these weird definitions, devs would have no idea how to use our API, which is just plain bullshit.
He even said some of these made up garbage terms were common terminology and i could google them. which i did, and of course they weren't, but this was already clear to me beforehand.

@lbfalvy anyway... I'm still relatively new to the unmanaged C++ world and until now i'm not the greatest fan of typedefs, since the examples i found in the code of a colleague so far weren't really helpful since they made the code more unreadable and obfuscated what was really going on. one would have to search over several files what these obscure types actually mean, only to find something really basic like double. also regarding your point of having a format AND a role: for me, the name of variables always described the role.

but of course there are examples like
typedef myType std::vector<std::tuple<int, std::vector<double>>>;
where a typedef would make the code much nicer and more readable. but also then the question is where these typedefs lie and if they are a potential dependency magnet when many classes use them, and if they should be exposed via the api or not...

@soull00t I understand your situation and I don't doubt that these can be abused. Everything can. They're a convenient middle ground between names and district types where you're not sure what if any custom handling is necessary.

As for the names, don't you think if you have a lot of names ending in Url or - even worse - a lot of fields expecting a Url with ambiguous names such as source, having a special typename for URLs would be preferable? As an added bonus, casting from strings could be explicit and validated and the common operations such as obtaining the origin would have an unambiguous location when you eventually get around to upgrading the typedef to a class.