Yeah exactly. The more imposing the variable name is the bigger the scope. Since letter variables are for a few lines of code in the middle of a function. Large screaming snake case constants are constants that span 1 or more files.

Still doesn't justify using i instead of index, or using i, j instead of rowIndex, colIndex. or k,v instead of key, value, or...... you catch my drift.

@@LeeorVardi I think it does!

@@xcraftminebb why?

@@Daren6111 as the original comment says. Just for very simple variables which have no meaning other than iterative variables like “int i”, or “char c” for one line variables. Or, like lambda function parameters (k, v) for map’s. Though I do see value in naming row / col.

off by one errors are like trying to plug a usb into its slot. You always bugger it up first try despite doing the same thing forever. Sometimes a third attempt is needed somehow 🤣

I disagree. There are three hard things: Cache invalidation, naming things, preventing buffer overruns, and hunter2

I disagree. There are three hard things: Cache invalidation, naming things, and developers agreeing.

There are only two hard things in computer science: Cache invalidation, naming things, and off-by-one errors, and cache invalidation.

secondthead orz

This is a good example! I find GoLang extremely useful for this since it is a package oriented language. And you are obligated to specify the name of the package as a prefix, except if you are in your own package. E.g. Let’s say I have a domain ‘vehicle’ logic and I want to have a factory that makes vehicles. In another package, the type would be represented as ‘vehicle.Factory’ and you would make it as ‘vehicle.NewFactory’ instead of ‘vehicle.NewVehicleFactory’. I find this extremely useful since it’s built into the language and I don’t have to battle with my colleauges about good names. Also, another tip for naming files: If you have a ‘vehicle’ that’s an interface, that interface would go in ‘vehicle.go’ file. The implementations would each have their own separate file called ‘vehicle_car.go’, ‘vehicle_truck.go’, ‘vehicle_cached.go’. This way, the interface and all the implementations are grouped together in a directory structure and not scattered across the directory, plus they are easy to search and access.

I ran into this today, got a piece of old Amiga C code I wrote as a teenager 30 years ago and couldn't for the life of me figure out what it meant. Really glad I've stopped doing that later in my programming life lol! And there were many other bad habbits like experimental code that's left in the code base without comments or documentation, it's no longer used. I kept it as a repository so that I could refer later to it. There was no version control back then. And GUI, util, handlers all mashed together AND spread apart in multiple files. It's a total mess! No wonder that the code was in a half baked state. I've managed to get the base functionality working again, thanks to the debugger, which I didn't understand how to use back then. Another mistake I made back then was naming functions inconsistently like CloseProjectWindow vs ProjectWindowClose and confusing the two. And then using PICloseWindow, using an abbreviation I don't remember and ordering it in yet another way.

I bumped into this when trying to modify an open source game, but I couldn't figure out what anything did because all the variables were incredibly vague abbreviations.

If you don't have context, you don't have enough information to mess with the code.

Even with context they can be hard to read, and without context they are impossible to read I do think he should have explained why code (in particular old code) used abbreviations. Maybe because it required less typing in a world without intellisense? If you consider the function DefWindowProc (in the Win32 API from 1995), does "Def" mean "Default" or "Define"? Does "Proc" mean "Process" or "Procedure"? The function header is: LRESULT DefWindowProc( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam ) What is an "LRESULT"? What is an "HWND"? What is a "UINT"? What is a "WPARAM"? What is an "LPARAM"? "HWND" is a WindowHandle. A handle is the ID of a resource managed by Windows. Not a pointer (so nothing to do with physical addresses), just an ID that identifies it (like a social security number identifies a person). "WindowsId" is more descriptive than "handle", but the word "Windows" is overloaded because it could be talking about the operating system or an actual window. So "WinId" might be better than "WindowsId". So maybe "HWND" could be "windowWinId" instead? "UINT" is an unsigned 32-bit integer. Why not call it unsigned32bitInteger? If the 32 needs to be flexible (maybe 64 or 128 some day) then it could be unsignedNativeInteger? Integers are common enough that "uint32" would probably be an okay abbreviation (the fact that the value 1 is physically stored as 15 zeros, then a 1, then 16 zeros is a whole other can of worms but I'll ignore that for now). And how is a "Msg" (maybe "message" would be better for the name for the parameter) which is usually something human readable that is meant to be read by humans just an integer in this case? Is it an instruction to the window? Maybe "windowInstruction" would be better than "Msg"? Even in a world without intellisense, a lot of abbreviations make no sense because it takes more effort to remember the abbreviations than it does to type out non-abbreviated versions. But... BUT... abbreviated code fits nicely in a 320x240 screen. So, we should all use abbreviations like "WPARAM wParam, LPARAM lParam". 640x480 killed the need for abbreviations. But it was just "the way things were done" so the practice went on for a long time after 640x480 was mainstream. Now a days we even have 800x600 so... yeah...

I personally wouldn’t go that far. While abbreviations like URL and DAO do require some context, I’d rather write ImageUrl or somethingDAO rather than imageUniformResourceLocator or somethingDataAccessObject. Somehow these names are less comprehensive than their abbreviations.

hah

Off by one isn’t hard because, well, it’s off by one

Top comment.

I've heard this quote be a hundred different things, only "naming things" seems to be consistent

@@evanbelcher because that's the joke most of the time "There are only two hard things in CS [literally anything], and naming things"

People who insist on "index" or "iterator" instead of just "i" are some of the most annoying types of people

@@NihongoWakannai I would love to see any remotely large computation written with full words. Ah yes, easingParameter < 0.5 ? 4 * easingParameter * easingParameter * easingParameter : 1 - pow(-2 * easingParameter + 2, 3) / 2; is sooo much more readable than x < 0.5 ? 4 * x * x * x : 1 - pow(-2 * x + 2, 3) / 2; Especially given the entire thing is pretty much always fully encapsulated. It's just hardly anyone actually interacts with math at this level in code anymore. If all you're doing is implementing a textbook PDE computation or whatever, there's hardly any reason to invent new names.

Definitely, but even then I think you should ask yourself: is there useful information I could be conveying here? It made a surprising difference for readability when I changed, e.g. df.apply(lambda x: log(x.inc+1), axis=1) to df.apply(lambda row: log(row.inc+1), axis=1) Or something like for car_i, car in enumerate(cars): ... My feeling is, x means a number, i means an iteration index which really doesn't represent anything, and most other things should be named. I work a lot with code that models the real world, though. If I were writing like a crypto library where the vector is just a vector and it doesn't represent anything, I can imagine using single letters more.

@@mytuppenny On some level, a crypto library is less likely to use single letters because it deals with concrete implementations. You may be writing an abstract library with lots of real world applications, but heavily grounded in math - that's where most of equation-like code comes from. Or consider physics sims. Between E, emf, and electromotive_force, emf would likely the best option to use in code.

writting lambdas is so nice. I looks very cool and is quick. But have you ever tried debugging a complex lambda you didn't wrote yourself?! :X

I used to like Hungarian. it made reading the code so easy.

aka why implicit none exists now 💀

​@@erato1look into "apps hungarian" vs "systems hungarian" tldr: hungarian notation in its original form is good, but the windows API guys corrupted it

Coordinate systems and loop variables are my exceptions to this rule. xyz, rgb, uv, hsl, ijk, etc. If you don't know what those mean then you probably shouldn't be messing with the code that deals with them.

Prefix them with vec

@milk guy I'd call hsl "hue/sat/lum". Short but also enough clarity.

Yeah, I take what was said in this video with a grain of salt. Sometimes, especially for variables with a short lifespan, abbreviating them makes the code a lot cleaner. Otherwise it’s just a mess with a bunch of variable names for simple operations

@@Hector-bj3ls also functional stuff

Or... It's 3am and you're too tired to name the variables hahah

@@josk8936 When you look at your code the next morning and start finding variables named "fuck_it" and "iGiveUp", that's your cue to maybe sleep more lol #soivebeentold

@@mk_jdilla Is it an integer because of i prefix? 😂😂😂

@@marcotroster8247 bYes

Many times refactor cost too much. Find more solutions that will prevent refactoring.

agreed - sure, it's a clear sign you should ask yourself some questions 'is there a better place right now?' and 'how unwieldy/disorganized is this utils file?'.. But also: 'am I letting perfect be the enemy of the good enough?' ... but in my experience, the answer is context dependent. Many times the best organization is something that reveals itself over time and overthinking/overworking it now ends up being a waste.

I often start with a utils class but usually end up refactoring its contents into dedicated classes that make more sense

Training (UKpostsrs teaching) typically rely on contrived and overly simplistic examples because ugly real world examples often require compromise. Few really experienced developers would want to deal with the comments section of social media.

That plural versus singular idea gets really problematic really quickly, because if you had an array of Things and just one Thing , you’re only one letter off from an autocomplete or typo messing up your day. If one of something is getting called Thing, you’d be better off using another longer word to append after it. Back in the day they always liked putting the type or whatever abbreviated in front as mentioned in the video, because that’s how they taught us to write code in a VB Class over 20 years ago. I prefer flipping that around so I can easily see the slightly more thing first, followed by the descriptor. So, for an array of more than one Thing, I would go with Thing_Array or Thing_List, that way if I go searching for “Thing” I can see where I used both forms of it, just in case I forgot what the prefix I came up with was. Sure, I could put a wildcard before the word I’m looking for, but I like putting them afterwards because that’s how I’m built.

​​@@kernelpickle You're entitled to your methods but not a compelling argument imo. messing up your day being like messing up 30 seconds max since even just a linter should catch this, and this never happens to me despite doing this all the time. It would take longer to fix in dynamic languages, but even python has type hints. Autocomplete requires your input, if you need an array, you're already looking for plural, if not, you're already looking for singular. The autocomplete should not have to do your thinking for you. And definitely not a fan of the postfix hungarian notation alike. Document your function in the documentation, not in the name.

​@@UnknownGamer40464 yeah, you're never gonna confuse a single object with an array, they're not interchangeable in code, your IDE will yell at you immediately

Function_Maker_Factory.make_function_maker(function_maker_factory, function_maker_params_dict)

One problem with this is that some words don't have a singular and plural version. For this reason, I will name my functions getMovie() and getMovieList().

Urgh, what a headache. People should not be allowed to write code like that.

I was just scrolling down to write the same thing! This is a huge trap that's a lot more common, and a lot harder to deal with, than anything mentioned in the video imo. So often in commercial codebases I'll see functions with variables like "fileList," "fileArr," and "fileTable," -- why do we need three copies of the same thing? What's different about them? Why is this one updated here, but not the other two? It boggles the mind and leads to a lot of wasted energy, especially when the original developer is long gone.

Better than f1, f2 and f3 :)

No no no no no. FreightCostCurrent, FreightCostStandard and FreightCostSpecial. Then they are all FreightSomethings.

One thing that helps is also commenting your code ._. I don't understand why people are simply ignoring the easiest way of solving all those misunderstandments(even though, of course, naming variables good is the best and most efficient way).

I'll break this rule in Python if I'm iterating an iterator other than "range". "for item in cart" works well, but "for iteration in range(5)" really doesn't especially once you start nesting loops.

I used to agree with this BUT I almost always avoid for() loops in modern code. Usually when I am iterating across a collection, I want the iterated elements but not the actual index. And when I do want the index it is actually nice to have it called "index". Of course if you are still coding in C99 or earlier, then the pattern of using "int i;" makes a lot more sense

Another one i can think of is if you are expressing coordinates/position, then you could have like an x and y variable denoting the position along the x and y axes

i & j is a bad combination as they are visually easy to mix up, especially for people with dyslexia. You also find another version of the problem with i & y or c & z. Both these pairs are a pain if you have to verbally talk about your code.

@@JoeSteele No you're right, there shouldn't be exceptions to the rule. If you need the index your standard library has a function for it. Pseudo code: for item in collection { ... int index = collection.indexOf(item) print(index) // There ya go bud } Another major issue of one letter iterators is that sometimes you have multiple loops with references to different iterators at different scopes. Things like working with multi-dimmenssionnal arrays for example. You will need to write multiple loop with i, j, etc... and use those iterators at different "level" of iterations which just make the entire code confusing.

Yeeees.

@david is a great video sommeliee

this is a sub at first vid kind of channel

@@zariumsheridan3488 an actually-turn-the-bell-on kinda channel.

hahah you basically had to reverse engineer it exactly like people really reverse engineer decompiled code

so he did what the cpu does with registers. Only have 8 so reuse when one goes out of scope.

I've had to clean up code like this... took hours to figure out what so many tmp and num and a and b and c... tmp2 variables actually did

Reusing variables might just come from ASM times Back then there weren't really things like names You just had some adress in memory you wrote onto And when the data at the adress fullfilled its purpose there'd be no reason to keep it occupied with no longer used data And with how important micro-optimsation could appear there was a good reason to do so But as soon as things hit anything that scoped variables there shouldn't possibly be any upside to reusing variables

That's the only sensible way to deal with such code. Rather put in some more work once than banging your head against a wall each and every time you have to get back to it.

Use context, no need to be overly verbose.

This. It is also the reason why if I write code for myself I actually use `A` for abstract classes. It's always annoying to try to instantiate those then find out "oh it's abstract, so I have to search which types even implement that" In my opinion it's even good for readability `AStream` or `AWriter` or `ATruck` makes immediate sense.

there’s value in following the conventions of the eco system you work in. There are rules for dotnet APIs, pascal case for externally visible identifiers, camel case for parameters, when to use Pascal case for abbreviations (at least 3 chars -> pascal case instead of all caps) That makes it a lot less jarring reading and working with code from different libraries, yours just being one of them. Arbitrarily adding something to public identifiers (like classes that get an A prefix) makes your code not just look weird. Imagine everyone would think they’re above those conventions. Then everything would look different for no good reason, except different individual pet peeves of individual authors, but in the end most programs would look like a mess. Because they are an aggregate of custom code but also using a lot of 3rd party libraries. I for interfaces is mostly due to it inheriting a lot of stuff from COM, and lots of COM interfaces had the I prefix for decades. Interfaces are different enough in semantics and performance characteristics (they force structs to be boxed when used as interface), that having the I is a very good compromise. It’s also clear that you can implement them however you want, as opposed to abstract classes, that will always have some things wired in a way that cannot be overridden.

@@DarthJane we go even further, we call OUR enum with E (and abstract A too). Maybe this is bad, but this is our convention and this is helping us.

Indirection is an epidemic in OOP. While I personally stick to the style guide in C#, I do think that if you can't think of a descriptive name for your interface implementation that doesn't clash with its interface (without the "I"), then you probably don't need an interface.

@@DarthJane "It's A Truck" - hm, i like that actually

Thats true, i think it is an acceptable exception. I do this sometimes in very small scoped / short lived arrow functions or lambda expressions as well, like persons.filter(p => p.getAge() < 16), if the surrounding context is immediate or its a long chain of one liner stream operations. In such cases you dont need very long or descriptive names really as they may just lead to more breakds and prolonging the lines of code in the method/function you want to keep small (but readable). But in arrow functions which are a bit longer or its less clear i still use full names as i do in pretty much any other case. I was trained in my first professional environment during an apprenticeship by a real "oldschool" hardcore senior Java dev for 2 years, who was a very kind and brilliant man - i read many important books because of him and learned from him that no name is too long and i adopted this ever since (of course, there is such a thing as too long, but you get the gist). I only went to university after i spend years in the industry, and my fellow (younger) students were sometimes really confused why my code is so "long" (not vertically, but horizontally). Or why i split code in so many functions/methods/classes. Funnily enough, to them it made to code "less readable/understandable". But that is usually born from a lack of practice in both writing and reading code at that point still. They are not "used" to how code looks and reads other than throwing some stuff at the wall until something sticks and the compiler is mute enough (with suppressed warnings) to fulfill some early grade assignments. Not used to scopes larger than 1-2 files. I guess theres still a core of truth to staying "as brief as possible", which is subjective.

@@stylishskater92 There is the famous saying - "any fool can write a program a computer can understand, but only good programmers write code a human can understand" 😉 For the splitting of functions/methods/classes, I believe a sensible middle ground has to be found. Often, splitting is really useful for self-documenting code. On the other hand, I saw people replace "if (end < begin) { invertFunction() }" by "if (shouldInvertFunction(begin, end)) { invertFunction() }". The first one is clearly more concise AND it tells you right away what the condition actually is. Here extracting makes the code harder to understand. Also, it obviously does not make sense to build a nice API with fluent builders, if people then extract the construction of an object to a method like "createObject(id, name, foo, bar, anotherProperty)"... As for single letter vars, I fully agree. OK for lambdas, list comprehensions etc, maybe as a loop counter (if anyone still runs classic for loops...?) but otherwise, something to avoid.

Should probably be [f"prefix.{c}" for c in columns], but I see your point

Or "for (int i = 0; i < iterationsNeeded; i++)"

@@nvcbl Very true. Extracting a variable CAN make sense in this case to avoid re-evaluating every iteration, but please call it after what it contains, not after what it's for ;-)

The newtype pattern is especially useful when you have a functions that accept multiple of the same type with different semantics. Like two different hash outputs that are both u32. It'd be easy to accidentally pass the wrong one. If you gave each a newtype then the compiler will stop you. Just like you were saying with distance. Also applies to time and a whole bunch of other things.

Or if your language specifically allows denoting units for types, like F#

In D, you can define a public alias for your type, which can help to simplify logic a lot.

In my opinion it can make the problem worse. Now you have a new arbitrary type that you don't know what it is at a first glance. Is "distanceMillimeters" an integer or a floating-point type? Or maybe it's actually a new type with its own structure? Furthermore, this "type aliasing" can cause a type-hell where you start to do things like "intVector" instead of "vector" - this makes you question whether a function parameter is of a special type that contains some special logic. While it's sometimes a nice idea, it's not something you should do all the time (maybe except using enums instead of booleans, although this is an actual new type, not just an alias).

Scala also has newtypes

Not that I use either but I think I'd prefer the way that it's done in Java (albeit less frequently, Java traditionally hasn't been as focused on interfaces as C#). Instead of IThing and Thing you'd have Thing and ThingImpl. It makes the interface you should use anyway have the "main" name and the default implementation comes alphabetically directly after the interface, making their connection obvious in most listings, be it of types or files.

​@@swapode I think using Impl in the name of type makes it a bit of ugly, but I do respect your point. But, in defense of C#, prefixing interfaces with 'I' makes them easier to identify in code and even using intellisense, as we have both classes and structs in C# and having something more to differentiate interfaces turns the differentiation to be easier. It also helps with the naming of things a bit, as we can think on interfaces as they where simple units of contracts for specific things (or even traits nowadays), like "IDriveable" (it reads like, I driveable or I am driveable, you could also write IAmDriveable) or "ICanFly" or "ICachedDao", for the most part it's actually interesting. So instead of having interface Car and CarImpl, you can actually have the interfaces IHaveRoads, IDriveable, IGasBased, etc... and have a concrete type Car implementing these.

It's there because C# is basically MS Java. And Java had it first.

@@tabularasa0606 At this point C# is much more than Java ever was.

ThingImpl is a disaster. It implies that you will only ever have one class that implements Thing. It tells me that you have have been told to use interfaces everywhere and you’ve applied the rule without any thought. The c# convention sucks even worse. It has the same problem but the additional “feature” that everything in your public API starts with an I. That’s not great for readability.

Reminds me of working with Joomla CMS. The convention there is to name ORM model/ActiveRecord classes "Table". Meanwhile, the application domain was publishing web content in HTML tables. Hence the not at all confusing name "TableTables" 🙃

pain

Let's not forget about HTMLHtmlElement.

This is so sad

@Ian Gregory this reminds me of some legacy databases I've sometimes work with. We have tables prefixed with the name of the database. For example, cms.cms_user, cms.cms_permission, etc. Makes me cringe whenever I come across those and I seriously want to write a migration to rename all those. What's worse is seeing column names following the same pattern where they're prefixed with the table's name, like user_firstname, user_lastname, user_username. AHHHHH! CRINGE!

Python also has the datetime.timedelta class. It's a little weirder than the equivalents in some other languages, but it works well enough.

I've been using type annotations in Python 3.8. In 3.8 they're kinda clunky (i.e. forward refs were added in Python 3.9).. they're still very useful. They help readability. Help you plan out functions (i.e. "I want to pass in these types of arguments and get these kinds). And they help Pycharm provide do type-checking, auto-complete, and find usages of a function or class.

​@@jocassid1 if you feel like regular type annotations are not enough, you can do "import typing" for mkre such as Iterator, Generator etc. Pydantic is also a way to make your code simultaneously more and less readable at the same time

@@khuntasaurus88 "Pydantic is also a way to make your code simultaneously more and less readable at the same time" - so: import pydantic as quantum_pydantic ;-)

You can't comment everything without being over explaining - that's having your cake and eating it. Just use comments where you are doing something which is not that obvious, and a good way to do that is when rereading the code, if you spend a while thinking what does this do, then that's where a comment is needed. Less comments kind of make the ones that are important stand out. It's like councils putting safety signs on walls. Warning - these stairs are dangerous, make sure you are holding on tightly.

@@Andrew-rc3vh I once worked for a company where one person would write the code and another dev would add the comments. They'd just work through the code and any bits they didn't get after a moment's thought they'd add a comment. Pass it back to the original author to check they'd got the comments right (and rework the code where possible to make it clearer) then send it round for review. Worked pretty good. I tend to over comment my code while I'm working on it but I do a pass before sending it out for review where I strip most of that out - it was only for me as I was thinking through the code anyway.

@@xlerb2286 Well if you have a good naming convention the code itself becomes far more readable. I think the problem with the system you describe is probably the most important comments of all are the times where the code is unconventional and may rely on things some distance away from where you are commenting. It depends on how complicated the system is you are building, but without certain comments it can take hours to figure out. The other trap is if the comment says something different to how the system works, such as if the system was altered and the comment out of date. It's one reason I prefer to rely on reading the code than too many comments. Consistency is the number one thing which makes the code readable.

@ the brogrammers with the “good code speaks for itself” mentality: just learn to write a meaningful comment about what it does, I know it’s hard for you considering the advanced level of autism

@@Andrew-rc3vh Even then it’s usually easier to just build the logic into a tester and comment what you want to do.

Agree with the third paragraph. I personally have sometimes benefitted to some extent by using terms such as BaseService, although I use it sparingly.

I agree that there is value in making type names clear as to whether or not something is abstract or not but disagree with the Hungarian approach. This can lead to the laziness pointed out in the video of things like BaseTruck. Instead, things should be named based on how they're really abstracting something. Take these class names for example: Vehicle, MotorVehicle, Truck, TrailerTruck, or Animal, Pet, Dog, GermanShepherd. It's easy to identify is a class is concrete or not if the name of concrete classes are specific and the name of abstract classes are more general. The only thing this leaves out is if a class is an interface or an abstract class, but I would argue that this is less important than being able to understand a clear hierarchy as in my example and also that you're going to need to know more about the classes anyways in order to implement them regardless.

Yes, I use single letter or abbreviated variables all the time and it makes the code MORE readable. Any time I see people spreading dogma about coding style like this it makes me think they don't actually program and just regurgitate what they heard online.

From your first points, I disagree in that I think `ALWAYS`, `NEVER`, `MAY`, and `SHOULD` are all great, super important words for hard rules. You're looking at these rules in the video and I think the main problem is that the rules in the video are just plain naive and badly thought out. Well crowd analyzed ideas that include these words can be excellent, and a rule defined this way doesn't prevent being given context to understand it

my man, why in the goddamn world would you want to save characters?

I started doing firmware in '84 in assembler and then C. I agree with you on that front. I've always been a big proponent of having a written coding convention/standard that can be passed along to new hires (others) that come into a project. I've seen WAY too much code where this doesn't exist, and 'the next guy' comes along and just does whatever they feel like doing. The result is never good.

From my experience translating programs from one language to another or reviewing old code that I remember almost nothing about, it helps a lot to add the type. And also use types that specify the size, like Int16, Int32, etc.

Why wouldn't it already be prefixed as ushort? Is it not C?

I'm an embedded engineer too and I absolutely loathe Hungarian notation. I've never found it useful, and what I have seen is type changes made without updating the var names. But when you DO update the var names, then suddenly your code commits have noise in them, likely obscuring actual changes. Never used it, never have regretted it.

@@marccygnus I haven't worked with C/C++ etc. in years. We never used type in variable names. We also never wrote functions/methods that were so long that one would get lost in a mess of code and not be able to see the declarations. I gave up on writing comments except for those special outlier cases or for API/interfaces. I can't tell you how many bazillion lines of code/comments I've run into that didn't match due to changes.

The very next recommendation after 'don't put types in variable names' was 'do put units in variable names'. Which, as you said, was the original intention of Hungarian notation. It's an interesting coincidence.

This. The original Apps Hungarian guidelines also specified to use "from" naming rather than "to" naming for conversation functions. For example, to convert from screen space to inches you might write: i_width = i_from_s(s_width); This made it easier to visually identify type mismatches because the prefixes on the left and right should always match.

Never heard of the term Hungarian Notation before. I prefix types into variable names simply for better readability of the code. It can be useful if I hadn't worked on a project for months and I have to look into it for some reason.

So now we can deride it while knowing its original intent ;-)

"the early programming leads for MS Word." Charles Simonyi. He was the lead for developing office (and is quite wealthy now got his trouble). He also has a PhD in computer science, so he's not just a business flak. I've read (and poked around in) C++ code that was a large ten effort that used Hungarian notation. It was pretty helpful, actually. Just because the type is declared *somewhere* didn't mean it's not way easier to determine it where you're looking in the code.

It's obviously a general rule and you will recognize when you can't do that for one reason or another.

Commodore basic is the same way. I think they're both based on microsoft basic? so maybe a microsoft basic quirk. Also I think Ti calculator BASIC is limited to single character variables? At least on the old z80 ones?

Programmer: **needs 677 different variables** Apple: skill issue

That's a bit like criticising driving schools for advocating the use of indicators (turn signals) because a Model T Ford doesn't have them...

@@craftsmanwoodturner They were making an interesting trivia comment, rather than criticising the video.

Of course working with position, x/y/z makes complete sense. for other places where there is no context like that, is what is being referred to here.

even then xPos *could* be better

In most cases yes, but say if you are working on a voxel engine where you have world coordinates and chunk coordinates, it’s nice to specify in the functions that it’s looking for xChunkPos, yChunkPos OR xWorldPos, yWorldPos

@@ABZZDEVYes!

Plus possible local positions within (child) components. But in general I tend to go more with "globalX/globalY/globalZ", "chunkX/chunkY/chunkZ" and/or "localX/localY/localZ". For rotational information I tend to stick with what I'm used to from CNC machines and apply the same "syntax" with A, B and C for the rotational axis. Like that there's really no way to mix them up and whoops by that we accidentally made a vector able to describe any given position and orientation in 3D space while mostly sticking to industrial standardisation xD@@blockify

Also if I’m doing something like a lil for loop I’d rather use i for convenience

To me i is a standard way to specify a simple index variable.

also, code comments are like, a thing, so if you want to keep the variable names short for convenience you can always just describe them in the comments, and there's no point having the names long if you ALREADY have to describe them in comments anyway

It's not about abbreviation, it's about context. If your context gives you enough information already, then you can abbreviate to xyz because you know what it's about. But if you are missing the context around it, then you should not abbreviate because this is obfuscating the code. The rule could be called: "never abbreviate context" rather than just "never abbreviate".

@@buggable i think this is a really bad practise. Dont choose bad names and describe them in comments. Choose good names and dont comment.

for (int primaryClassArrayIterator = 0; primaryClassArrayIterator < cArr.length; primaryClassArrayIterator++) { for (int secondaryClassArrayMemberIterator = 0; secondaryClassArrayMemberIterator < cArr[primaryClassArrayIterator].getArray().length; secondaryClassArrayMemberIterator++) {

you missed the point here

Using the words "always" and "never" invites lots of "what about"s. I think the guideline (not rule) should be "Favor readability over terseness". There are obviously some things so common no one would get confused; like using i for a loop iterator, using x and y for 2D coordinates, etc. I would say in the latter case, Player.pos(x,y) is much more readable than Player.screen_position(screen_x_coordinate, screen_y_coordinate).

@@BrianMelancon whats why you should never use "always" and "never". I say that sentence often and yes, the using of the word never is to underline the point :-D

Yes! There's a small amount of conventions like "e" or "evt" for eventhandlers and "e" or "ex" for exceptionhandlers

Well it could get confusing if the programmer, for some assmad reason, had decided to use y for the 1st. horisontal axis, z for the 2nd. horizontal axis and x for the vertical axis. I guess one could technically name them horizontalX, horizontalY and verticalX or something to ensure less ambiguity even in contexts with "implicit" conventions like in coordinate systems.

I definetly use only movieCount. Num or number is an ambitious word for amount of something (and 'amount' itself, too).

Well said. People treating guidelines as some kind of immutable law makes code worse, not better.

@@kristianjensen5877 this does piss me off, in minecraft, your coordinates are x and z for where you are in the world, and then y is height. it annoys me, but i got used to it. i'll never do that in my code because no

I think it’s also useful for creating helper methods for working with external libraries

But idk I’m still a junior so maybe there’s a better way

It can be, but is definitely an overused name just like "Shared" and "Common" All work sometimes but if a more specific name can be given then that often makes code easier to read, packages easier to navigate and when you forget the name of the method but kept the class name simple gives you a much shorter list of methods to scan through when you're looking for it

also good for unit testable methods without having to expose all the methods in a class that would otherwise contain these methods

Agree but i would add a suffix or a prefix to specify what kind of utils they are, to avoid multiple utils having same names.

Yup, and when you glance at the code you know its an interface and can plan accordingly. Its more readable.

If i worked with a library or framework specialized for apple or apple products, I would be disappointed if there werent i-prefixes everywhere.

We use exactly that - "I" prefix if it is an interface-class, "_t" suffix if it is a plain data-class, and very few other rules on naming stuff. It does make it easier.

I believe that the I-prefix is just a variation on the Base- or Abstract- thing. Like, a WeatherService and IWeatherService could be better named as GoogleWeatherService and WeatherService. I would keep the I-prefix in languages where the standard library uses that naming scheme, but still apply the more-specific class name (i.e. in that case they would be GoogleWeatherService and IWeatherService).

bep

2. i enforce this rule in my company. and additionally, if a variable or function returns a specific data type, especially if it returns boolean, state the variable/function name in a way the boolean would answer it like a yes/no question. E.g. instead of "checkAuth", write "canLogin" or "hasAccess"; if a function checks whether all systems are online, instead of "allSystemsOnline", say "areAllSystemsOnline" because "allSystemOnline" could be performing an action that makes all system online, but if a function is called "areAllSystemsOnline", then it is obvious that function is only going to perform a check rather than actually trying to bring all systems online. Also, please please please, bar some really rare scenarios, don't use negative words in names. !$user.inactive is just that much harder to read than $user.active. we are dealing with enough logical challenges already, no need to add double negative into the mix, ain't nobody got time for that.

1. True. In some cases single char vars are ubiquitous. Like the "i" in loops. Or short names for "exception" in a try-catch. But in custom cases like "durationSeconds" I'd strongly prefer using that name as the var name - as opposed to a short name and a documentation/comment. As less docs/comments is just...less source and fewer stale things that can become outdated

@@BenRangel yeah. if it's milliseconds though, then "durationMs" is fine for me, because "ms" is a very well established abbreviation (as long as it's obvious that it refers to time context / duration). relying on extensive documentation is fine if you're writing an API or a library. out of my experience, comments generally aren't read (even when they should be) - developers seem to develop some sort of a "comment blindness", probably because they're so often outdated or incomprehensible to begin with, so people kinda give up on them by default. i'm doing my best to avoid having to write any comments. if i find myself in a situation when i'm tempted to write one, more often than not it means the code needs to be rewritten. you need to explain what those 10 lines accomplish? extract those 10 lines into a well-named function; make that name take care of it. cases where comments are unavoidable happen sometimes - like a complex workaround required by a quirky bug in a third party library - but they're few and far between.

@@vibovitold Agree with everything. All devs are familiar with "ms" ✅ and docs are worth if it's used by lots of people, especially public apis ✅ I think it's fine to comment methods in a format that shows up as hints in editors. But wouldn't do it in my own teams codebase - I figure most of the time if the method name and args are simple and clear we don't need that comment. I don't hate them though. But I mostly use comments as a rarity to make people look carefully. I mostly comment weird stuff. Such as business decisions that seem wrong. Like "this format is obscure but we need it for marketing" (used to rely on git history for that type of stuff but after migrating between repos and file structures that kind of history can become obfuscated)

In my company we use Utils for misc functions and extensions which are used in mutliple projects. Something like calculating a hash for some data which just doesn't warrants making a complete single funtion class out of. And some Extensions for EnitityFramework like AddIfNotExists or stuff like that.

get is commonly used for code that does a GET request

@Jabberwockybird maybe for some, but never for my projects

wouldn't "request" as a verb make more sense than "pull"?

@@fiona9891 depends, there is also a subtle difference there too: 'reqXxx()' implies the remote host may potentially reject the request, whereas 'pullXxx()' implies that the remote host only servers to provide information.

​@@fiona9891 the one I've seen and prefer is "fetch"

Yeah this is fine imo I think the real problem is with names that are essentially just euphamisms for "miscellaneous" as in they have no qualifiers of what they relate to at all, like "utils", "shared", "common", "globals", "constants" Often these things contain a bunch of random methods or values, that could actually be organised but just aren't because the thought didnt occur or a good name was just not happening

@@licriss and let's not forget the immortal "SomethingManager"

I was going to say the same thing. If you're using a 3rd party library and cannot simply add new methods to existing types, this can be useful. In C++, I would go with a utils namespace, or perhaps a {module}_utils namespace, rather than a class.

You could build a class to extended it. A decorator of sorts. You might want to avoid creating unnecessary objects, tho.

@@LeoFuso Yeah, I wouldn't create a class if I don't need state.

This! 💯

Also if you press "I" your IDE will suggest you every interface relevant to that context

Yeah but his other point kinda covers that. You have an interface with the same name as another type, you should rename one of them. I used to think a little bit of hungarian notation was fine (I learned to program in game maker so half the assets in my game started with spr_ and obj_) but after learning a bit of Haskell and Rust (where the type straight up won't compile if it's not PascalCase, and variables won't compile without camelCase/snake_case respectively) I realized how unnecessary it is to ever use hungarian notation.

It's probably about convention or maybe something inherent in a programming language I don't know but if there is only one planned implementation for the interface (which is implied by the interface and the implementing class having the same name) then why bother with the interface at all?

@@fletchcanny717 Renaming them just for the sake would be stupid, you would be forced to come up with artificial names all the time. I'm so glad we're prefixing interfaces in C#.

@@lahodal if you're struggling to come up with good names for your interfaces thats a good indicator that it's a bad abstraction. So many problems are made easier without the complexity of polymorphism.

Except click is always an event; close_button_click would be more descriptive.

Ha! And here is the comment I was watching the video for. Because I generally use positive Boolean property names, but wondered when I had a “hasConstraints()” function. Because it is used in a heuristic, I am only interested in a decisive “false”, while a “maybe” and a “yes” can be merged in the “true” return. So for this particular case it would be more straight forward to make it “isUnconstrained()”. 😅

@@mleise8292 I'd go with the former, because that extra "un-" can throw a spanner in the logical works.

Re base types, maybe it signals that the class is not fit for _any_ use! 😅 All jokes aside, I am guilty of this, too; and although I disagree with some of what was said, in this case I plan to change my ways.

@@creativecraving I don't think I will, personally. I worked at a place where the convention was to have subclasses share at least one word with their superclass whenever possible. So the abstract class might be called WindowBase, then there would be a concrete Window class, and that one might subclass into a DualWindow class, which in turn might be the base for a DualScreen class. Okay, so this is kind of a messy example. But it made sense for WPF stuff. The point is that it was easy to tell by sight if there was any inheritance going on, and made naming easier.

Good practice, maybe. But ugly as hell code.

@@yuli3873 I've gotten used to it after dealing with type hints a bunch.

In Addition, the function shouldn't be written in camelCase (PEP8) as seen at 3:33

Type hinting are glorified comments which arguably makes them worse than useless.

@@isodoubIet That’s only true if you’re using a basic text editor. The real strength of type hints comes when they are used in conjunction with a modern IDE or code editor which it can read the hints and give warnings when you’re using the wrong datatype.

The naming convention of VerbNoun is a _very_ handy one.

This is pretty much the same as Hungarian notation, just a little better.

Yeah this for booleans is one of my favourite naming conventions

@@MichaelPohoreski Yes, but when the underlying language is English then I found the "verb" part (too) often be indistinguishable from a noun. English just has too many words that are identical as noun and verb: capture, run, start, stop, display, screen, filter, tag, mark, file, store, jump, find, loop, click, push, in-/decrement, in-/decrease, change, set, update, call, signal, message, ....

Ruby allows for question marks in method names so you can replace (for example) 'isValid' functions with 'valid?'. Really enforces the idea that you're asking a question and getting a boolean answer.

You are right about the origin of the single letter variables and that's the same reason hungarian notation was around, as an helper, for old programmers the letters aren't gibberish, for newer programmers they definitely sound like that. 'strCwd' sounds like a seizure but an old programmer will recognize that it's a string representing the Current Working Directory. We don't live in a low memory world anywore and we should work ourselves up to write good variable names for the future. As for the axis, x_axis would be better in my opinion, or even horizontalAxis. As programming progresses many people that aren't from the field approach it and many fields outside programming acquire programming in their daily schedule, if a math major finds an x he might solve for it, if a pirate finds an x he might start digging, if I find an x, I would likely hope she doesn't notice me because it would be weird. In short, you should make sure that every other person reading your code who isn't in aware of your context can understand the code! :)

@@impromptu222 I can see your point, but I would still say thay things like coordinate system labels are fine as single letter names. If, for example, you're in the code that deals with uv coordinates and you don't know what uv means then you probably shouldn't be messing with my procedural mesh generator. I wouldn't want to work with a vector library that named the axes horizontalAxis, verticalAxis, and depthAxis instead of just x, y, and z. I also wouldn't want to work with a colour library that used full names instead of rgb or hsl, etc. Sometimes the single letter names have a we'll known meaning in a particular domain. In which case the single letters are fine. I'm not saying it doesn't make it harder for new people to said domain to understand what the variables mean, but even having full names in those cases probably doesn't make the code much easier either. But, before we have a disagreement about something we don't disagree on, let me reiterate I agree that in general full variable names are a good thing. Especially when you work with developers whoes first language is not English. Abbreviations may seem obvious to some, but full words enable easier translation.

Also Fortran had pre-inizialized variables that start with specific letter

other use for single letter variable name: variables that have no real meaning for a dumb, simple example, compare: add leftAddend rightAddend = leftAddend + rightAddend add x y = x + y

@@impromptu222 A mathmatician who sees a member variable be called Vector3.x will not try to solve for it.

This guy is not a good channel to learn by. He often makes an argument for his opinion without logic or rationale, rather just his personal taste. So many bad opinions in this one video alone. You want a real dev? Go watch tim correy... Not this egotistical fluff.

​ @Taylor Brown This isn't bad if you are a lone/new developer. Developers do need guardrails. But if your working on a large project the architect should have defined naming standards. I always document naming standards for my projects. Things like when to use certain prefixes or suffixes. I even go down to the level of how to name methods like the differences between GetItem(), FindItem(), and SearchItem(). On top of that we code review to ensure enforcement of these practices. So its a good starting point, but if one of my developers created an interface that didn't start with the letter 'I', I'd chew him out like there is no tomorrow.

I would argue that you should almost never have a 1-1 relationship between interfaces and classes. If your class does more than one "thing" you likely need more than one interface, and I can't legitimately think of a situation where you would want to have something public in a class that you wouldn't in an interface. If you need access to more than one of those, just use the whole class (instead of an interface with the same public properties), and if you need access to just one, just use that one interface. This way of separating responsibilities forces you to think about what your class does, rather than just bundling everything into it, guiding you to cleaner code.

@@Xastor994 It all goes back to what you’re building and how you’re building it. My teams always use contract driven development. They get together and first define the interfaces for the various layers of code. Then each developer takes a specific layer and builds/tests it in parallel using the predefined interfaces. That’s not the only use case for 1-1 mapping of interfaces and code implementations. Test driven development prefers interfaces over classes for mocking purposes. Code generation, dependency injection and may patterns work better with interfaces.

@@Made2Watch1VideoFUGo Mate, a contract-based development makes things better actually. You team should give the interfaces a much more abstract name, like "Truck", and the class, "TrailerTruck". Interfaces should always have a more abstract name than the class. Having the same name just with an "I" prefix for the interface makes the code much less readable. I'm pretty sure the class does something more than the interface.

Yeah, I highly doubt that naming your loop variables "horizontal" / "vertical" (or "row" / "column") in lieu of "x" / "y" is ALWAYS superior.

Sorry, are they x, y and z positions or x, y and z rotations? Are they absolute or relative? The only reason where x, y and z - in my opinion - are valid is if they are part of a class that explains what they are; such as rotation.x

@@LindaJuffermans Nope. Just use sensible conventions in your project. Most functions will be called sth like "move_to" anyways. x, y, z are generally associated with coordinates. If you need to store rotations, you can use aviation terms like pitch, raw and yaw, though I prefer simply using x_rotation, y_rotation, z_rotation for these, as I don't have to consult a dictionary to remember which is which, and it's kinda arbitrary in two dimensional space. If you store them in a struct, I'd probably just use a three dimensional array called either pos or rot, but that's implementation detail. If you wanna expose them, you need to consider what interface makes the most sense for the consumers you have. You can implement get_x, get_y, get_z and get_x_rotation, get_y_rotation, get_z_rotation. Makes it very clear what they are. If the rotation ones are missing, you still know from the project's convention. Or you simply return a struct with fields x, y z, or a 3 dimensional array for functions get_pos and get_rotation. You can also call it get_x_pos (etc), it's just important that you're consistent and thus have reliable conventions. Whether it's relative or global again depends on context. If I have a get_pixel function for my rectangle struct returning a color, which takes a x and y, it's gonna be relative. If I have a get_pos returning a position struct with x, y, z, it's clear that it will return either global coordinates, or maybe coordinates within some parent object it is a member of. If you need to offer both, or it's actually unclear from the context, sure be specific. Just don't preemptively be overly verbose just because "maybe we will return relative coordinates in other places one day". Only be as verbose as you need to be at the time and if you add sth new which makes an old name confusing, that's when you can think about a refactor. Makes iterating faster, since you won't have wasted too much time thinking about all possible future usecases before throwing it away and refactoring everything.

psh, as if half their code base isn't aliases

Thanks for the feedback. I'll definitely lower the volume next time

@@CodeAesthetic thanks, keep up the good work!!

I was gonna say the same thing it’s a little overpowering sknskdnf

@@CodeAesthetic honestly, don’t be afraid to just get rid of the music. Music for the sake of filling sound can become more distracting than anything. Have it at key points if you want (it helps make an impact) but let it fade out during explanations. Also, you voice alone sounds nice and is nowhere near the grating others have that need music to drown out.

@@grepgrok8735 Complety agree with you. Found myself way more confortable at 6:40 whem the music stopped, even without voice, but coding in the screen. Apart from that, really good content, keep it up!

No. It actually comes from a Microsoft developer, Charles Simonyi (who's Hungarian). They were using a language (BCPL) without types, where every variable was a 16 bit word. He wrote a whole whitepaper on this. As the video stated naming variables is hard, so he focused on creating a system for it. Including the type in the name is just one thing in there. It's not needed, if you're using an IDE to read code, but sometimes you don't have access to one. It might still be useful to see the type of the variable without having to scroll back to the declaration.

Hungarian notation, when in a typed language, was also originally designed to tell you the parts of the type that the language didn't understand, like the units. It's an integer, but is it measuring vertical pixels, horizontal pixels, vertical points, or horizontal points? If you see (hpxMargin+hptWidth) you know it's wrong. If you see { vpxIndex = hpxIndex + 1 } you know it's wrong. You can't add pixels to points and you can't change horizontal into vertical. So instead of just a float, you have "milesDistance" or "kilometersDistance" or "altitudeMetersCurrent" and you'd treat those as different types, even though they're all three floats. (But of course you wind up abbreviating the prefixes.) In languages like Ada with better types, you can actually say "make a new type that's an integer but only interacts with other variables of this new type" so you don't have this problem.

good ole unit counter, ii

@@darrennew8211 Properly, there are two types of Hungarian notation, Apps and System Hungarian. Apps Hungarian encodes the semantic type, like vertical position, row, zero-terminated strings in languages that don't have those as a type, etc. System Hungarian encodes the programming data type, like int, string, pointer, etc. Apps Hungarian is still a good idea, but less necessary now that we have modern IDEs and can cheaply create types to indicate vertical position, row, etc.

@@darthbob88 I think unless your system enforces "newtype" (i.e., you can't interchange float miles with float kilometers) app hungarian might still be useful. Modern IDEs are definitely helpful compared to when Hungarian was introduced, for sure. I can imagine no reason for system hungarian notation even back then, assuming your language was statically (and hopefully strongly) typed in the first place.

I agree. Not using abbreviation is only good for relatively simple class, but not when you need to get data from member of member of member of an object, and all of them have long names. Also not everyone has 4k monitor. I'm still working on my 1080p laptop and a sub 1366x768 monitor.

Eh, it makes sense to abbreviate if the abbreviation is more canonical (like "i" in for loops) but gone are the days of 80 column displays. We have the aspect ratio to display slightly more verbose names, and I'd much rather read code which has too descriptive variable names than too short names

@@gazehound Screens have gotten bigger, but our brains haven't.

Abbreviations are mostly bad. Except in such cases as the abbreviation is so well known that it's effectively a proper noun. It should be common enough that even if the reader does not know it, they can pop it into google and the first result is the definition. I would definitely just call it "Users" with an integer type. Unless I also want to also work with an array of users, in which case it would be preferable to do len(Users) instead of having it as a separate variable.

I think abbreviation is fine, but don't over-abbreviate Like, "std" and "NumUsers" are understandable, but "s" and "NU" aren't

I believe the best is to have the function named "somethingOnClick" and call the actual "somethingSubmit" inside it, no? As you may want to call several other functions on the same onClick event. Genuine doubt, i've been working with javascript for some time now but i don't like it that much, nor have I looked into anything javascript related outside of my company's code

Yeah that checks out. It seems that everyone that writes shader code is afraid to use a variable name more than 3 letters long xD. Makes reading shaders you didn't write a pain in the ass. (but yeah for math stuff like you mentioned it is very helpful to make the math and variable names line up, so that gets a pass)

@@lydianlights having the maths as the comment is pretty great too

" int nbOfCookies; " is the one that i use

n_cookies has become my standard form since doing a neural net book. It's clear and concise. What more could you need? :)

int cookiesNum;

I prefer nCookies

I would use cookieCount myself. If I saw "cookies" in code I'd assume it was the actual cookies, not a numeric.