@@sven-o In the real world, tabs result in endless problems. There's a reason well-intentioned projects start off with tabs and switch to spaces but never the other way around.
I've never really understood the "don't use comments to explain how something works only why it's in the code" argument, but if the example in this video of explaining "how" is what that rule is supposed to stop, then I totally get it now.
It’s like, if you are spending a lot of time explaining how your code is working… usually (not always but usually) that code is 💩 So spend the time making the code better instead of explaining how bad code works.
Writing good code is not just about writing code that works. It needs to lead future maintainers through its intention. That's why naming things well is so important too.
1:35 You've got the example wrong. We're not `grep`ing the output of the program for the error message (splitting up the error message in the source code isn't going to cause it to be printed any differently anyways): we're `grep`ing the source code for where that error message is, so we can see under what circumstances it gets printed.
My understanding is that it’s both. Splitting the error message in the source code will cause the message that is printed to be on multiple lines therefore making filtering logs a bit annoying which is what I was showing in the example. The same thing applies in the reverse case when grepping the source code for where the error message is. The reason I didn’t put time into explaining that is because most modern logging implementations will have the file and line number etc where the error was thrown in the stack trace so you usually don’t need to grep the source code like you mentioned.
I was confused by what you said about being able to split up lines by concatenating them. In your example, sure, the program output is still in one line so it's possible to use grep. But what if instead, you wanted to find where that error message was in the actual code? Now you can't find it, because it's split up...
I'd argue that searching for the message in the source is way more common than grepping a program output. You would usually see the log when inspecting the output after an error, then search for it to find out what went wrong in the code.
I disagree with 8 tabs example. I used to reading code 2 times more zoomed in than an example you've showed. This makes "too far to the right" mark go to, like, 4 levels of indentation. And also you've showed an example in Go which isn't an OOP-obsessed language. In C++ you'll get 3 levels of indentation just from method in a class in a namespace, and having 24 space nothing always at the start of the line seems bad for me.
Indeed. The best advice I learned in coding is that all these programming tips, even languages themselves, are simply philosophies of some person, so don't make them sacred texts. My laptop screen isn't thay wide so I also prefer 4 char identations even in a language like Go
It is much easier to prohibit TABs in your VCS than configure every single editor and utility, given that some of them are 3-rd party and/or not configurable.
You only need 4 spaces if you have multiple indentation levels. Otherwise 2 will suffice. It's not about the size of the code as about how many indentation levels exist in the code
I usually write comments on the how and why when I come back to the code later and can't figure it out in a couple of minutes why I did it this way. I mean it's no big deal, there are additional lines that don't bother performance or disk space at all. An issue arises when it's more comments than lines of actual code, or something along those lines, when the code reading flow is interrupted by comments.
Agreed, I would rephrase the comment tip as "Don't write a long explanation comment if you can rewrite the code to explain itself, and be SHORTER than the long comment". Also assuming that rewriting the code to be longer doesn't increase performance cost. Sometimes smart one-liners aren't there just for the sake of being shorter, but to actually do something in a more performant way.
Hm. I have to disagree with your last point. It is far more useful to describe the "why" rather than the "what". The "what" should be readily obvious if you wrote the code correctly.
Tabs depend on the language. For example, it's virtually impossible to code java with 8 space tabs as it is all nested scopes, inner classes and so on. Languages like rust with his pattern matching let you have far fewer nested or changed if statements.
He's literally everywhere since every single one of these are from the linux kernel coding style guidelines which he wrote. www.kernel.org/doc/html/v4.10/process/coding-style.html
aw man, i use different indentations for different languages. i follow the standards. for python, i use 4. for bash, i use 2. for c, i use 8. but it does not really matter. just go to vimrc and change tabstop and shiftwidth and remove expandtab. your identation will automatically update. you might have to :retab if you were using expandtab before. if someone else gives you a project, change your tabstop and shiftwidth to match the indentation of that person's project. if they're using spaces, set expandtab. match your vimrc settings with that project's settings so that everything is uniform and consistent and easy. if youre working on multiple projects with different indentation levels.... then..... if theyre different languages, autocmd will be fine. if theyre the same language, then..... if you know vim, you'll figure it out.
@@luizAugustoll maybe it was 20 years ago. I looked it up today and most people prefer 4 in C today. i don't remember which standard i read, whether it was GNU C Standards or the C used in Linux development but one of the two said to use 8 spaces per tab. the default in vim is definitely 8 though. you'll have to add tabstop and shiftwidth to change it from the default to 4 spaces or 2 spaces.
I don't think you go far enough with your point about comments. Don't tell me how, don't even tell me what. If I can't get a pretty good idea what some code is trying to achieve by reading it then it's probably no better than the code where the programmer felt the need to say how it works. The point where you need a comment is when you need to explain *why* it is the way it is. For example: "This string copy ends up being used in the render loop so if you don't squeeze literally every cycle the framerate is going to tank". Ok great, now I know that if I apply the code clean up then I need to ensure it optimises to the same code and also where I should probably go check performance before releasing it to production. The key part is that if the code looks out of place then the comment is there to try to convince me that doing it this way, as opposed to the way the rest of the codebase works, was the right thing. (Oh also, interface contracts should be documented as a matter of expectation management but that's not really a "comment" even if they use the same mechanism) Also, the right number of spaces that an indent should be is whatever my auto-formatter is configured for and the correct way to get those number of spaces is to use the tab key. Also, if I want to go back to the previous level of indentation, I should be able to press backspace once while at the (indented) start of the line or sometimes shift-tab. To put this another way, the editor should act in every way shape and form as if Tab characters were being used but should only ever write the indent as space characters to the file system. I personally think that 2 characters is too little and 8 characters is probably too much but that's because i'm getting on in years and my eyes don't see as well as they used to but, ultimately, whatever is agreed upon as the auto-formatter settings is the correct value.
Come on, just set max nesting level in your linter config and it will enforce the rule no matter what tab size is. Really, all of the problems have already been solved by prettiers/formatters and linters.
@@christernilsson1 The discussion is over only in fantasies. In the real world, tabs result in endless problems. There's a reason well-intentioned projects start off with tabs and switch to spaces but never the other way around.
@@DemPilafian please list the reasons. Here are mine: tabs are easier to insert and delete. Tabs takes less space. Tab width can be individualized. A company can change the standard from four to three spaces with a keystroke. And the main reason: there is nothing left to discuss.
@@christernilsson1 Tabs are theoretically better than spaces in every way. In practice, however, tabs are a mess. 1) Web pages and command line tools display tabs with ridiculous amounts of space. 2) Indentation and alignment are different, and alignment requires spaces which get destroyed by tabs. 3) For whatever weird reason, experienced smart developers occasionally submit pull requests with some indentation as spaces instead of tabs (the reverse does not happen). The real world doesn’t care that tabs are theoretically superior. Engineering managers get tired of tabs interfering with code diffs.
@@DemPilafian Copying indented code from different ai:s and other sources will suffer from having different amount of spaces. All tools should be configurable, like VS Code.
First of all, it's not actually funny when Linus says nasty things about **anyone who writes code in even a slightly different style then he does** and it's not actually funny when you parrot it, either. He's been working on his attitude in recent years, because he understands how it has hurt the Linux community. You should participate in that reformation. Second of all, code styles developed in kernel code in C have a completely different set of requirements than userspace code. Any attempted application of one style to the other should be taken with a massive grain of salt. Third, use your IDE to add blank indent markers and they will be easy to see regardless of their width.
If you use a beautifier, there won’t be any problems. Just make sure same settings are used and run it before before you commit and make sure it compiles.
@ well, it solves many problems. If you don’t like tabs or something, just let it beautify the code to what you like and then beautify back when you check in. That’s what I liked about vb6. Having said that, there were those that wrote horrible code. My c++ code called vb6 code which was very good for what we wanted.
@ I should mention some things I really don’t like which are not solved. I really dislike code that is written such that it’s difficult to debug. Don’t use one line to write code that does two things and no nested functions!!. A colleague of mine had a switch statement where only a few cases were considered and there was no default which he claimed would never happen. I did introduce a default and it didn’t take long before it did much to his surprise.
Honestly don't think smart code affects readability, if people can't understand a regular function without max 3 lines of hints, it's really a skill issue on their side, unsmarting you code for people who have skill issues is some really unnecessary work. Not being mean just being real, there is nothing wrong with coding smarter. With all the LLMs going on understanding code shouldn't be a problem.
Clever code is not useful for work. Not readable in one look. Other devs should be able to understand your code clearly for them to update it with confidence.
It actually does animal -> Animal (First letter capitalisation) if Animal[0] > 'Z' Animal[0] += ('A' - 'a'); The lazy C way. Python is just toHigher() Then if exist.
8 char is shit. Because good variable names aren't abreviated. So the single if ( LongAssVariableName > SomeOtherVariable && LongAssVariableName < TheWidthOfYourMom.InCentimeters() ) { ... } will be too much to the right. Also, Im shit language like Java where everything is inside a class... Thats 1 less Identation.
So you maybe only like scripting languages, because functions as entry point is really important because you can't run code all over the place. So is Java, it just use classes instead, not really different. The C entry point must be a function and called main for example, allow the C runtime to do things before run, even assembly need an entry point.
0:45 let's cut to the chase. How are you going to deal with html and json files then? Scrolling left snd right 5 times a second? Having preferences is fine, but claiming they indicate good or bad behavior (as in bad programming habits) is pure nonsense. They're just conventions, and the only downside is they don't work in the outside world. But within a personal project, or a team which agrees upon those conventions, there is not right or wrong style.
Regardless what you think about these things and whether they are up to the task they're allegedly made to solve, they are still standards in the industry. Whether I, you or they like it or not, they (amd other things you don't like in the industry) are a reality that you, I and he will have to adapt to at some point, at least if we were to engage with the wider audience and teams we're not with at the moment. Suppose you're a twch company, need tech workforce, preferably in C, but the entire workforce is too dumb and can only code in [choose a language so that I don't offend you unnecessarily]. And suppose you've been looking desperately for a C programmer for 5 years, and you can't sustain your company anymore (i.e., the ugly reality that json and html are bad solutions and need be disposed of). Do you bet on the utopian programmer that may (i.e., the future in which there would be no json or html, which are the bad inventions the industry adopts today) never come, or adapt to reality, as harsh and ugly it is, and try to make with ehat you got, in the tech workforce market? I don't care if json is the worst thing in the world in this regard. What my point is about, is whther you liked it or not, you have to live with it, and adapt, as long as it is going to be the reality for the foreseeable future. I haven't worked with html or json much, so I'm not dying on defending this hill, and have no dog in this fight. I am just concerned this self-obsessed attitude still lingers in this community. But who am I to envision a society that deviates from normal human behavior? People were, and will ever be believing the sun and the entire universe revolve around their thick skulls. Bit sorry to offend you, and I know I'm just a commenter and you are the one who did the work and made the content, but just have some humility.
Argument falls apart a bit in the context of OO-based UI toolkits where nesting of components is expected to be deep. Yes, one can break apart monolithic components into smaller ones, but even some of the smallest can have a significant depth to their tree.
@3:45 I call bullshit. If someone can't understand basic C theyve no business being in the code. I'd say your restructured code is harder to understand.... I'd be worried you wrote it like that for some obscure case I'm missing.
Weren't banned, just were removed from the ability to sign off on their own code commits because of increasing geopolitical tensions. Believe me, it's safer for everyone involved when they can't be forced to put a backdoor in Linux.
![Ice On My Teeth - ATEEZ エイティーズ 에이티즈 [Music Bank] | KBS WORLD TV 241115](http://i.ytimg.com/vi/c-n92OgbbwA/mqdefault.jpg)
If you care about tab width you got no real issues
100% correct. That's why all real developers work alone and never share files with anyone.
@@DemPilafian Real devs can just adjust tab width if it really matters to them
I agree, the lead maintainer on the Linux Kernel has no real issues to worry about.
No cowboys allowed on my squad, since I've made the pipeline.
Use Linter or expect an error message blocking merge request.
@@sven-o In the real world, tabs result in endless problems. There's a reason well-intentioned projects start off with tabs and switch to spaces but never the other way around.
I've never really understood the "don't use comments to explain how something works only why it's in the code" argument, but if the example in this video of explaining "how" is what that rule is supposed to stop, then I totally get it now.
It’s like, if you are spending a lot of time explaining how your code is working… usually (not always but usually) that code is 💩
So spend the time making the code better instead of explaining how bad code works.
Writing good code is not just about writing code that works. It needs to lead future maintainers through its intention. That's why naming things well is so important too.
If you are implementing some known algorythm then just put a comment and link the source, you will do everyone a huge service.
Comments are best for WHY not HOW
@@steve-wright-uk if you implemented algorythm and didn't invent it yourself, why wouldn't you link the source to help people understand what you did?
Strangely meditative, straight to the point and so smooth that it doesn't need outline/introductions to connect the topics. Well done!
Smooth transitions between concepts, meaningful commentary and instructive examples. What a nice video!
1:35 You've got the example wrong. We're not `grep`ing the output of the program for the error message (splitting up the error message in the source code isn't going to cause it to be printed any differently anyways): we're `grep`ing the source code for where that error message is, so we can see under what circumstances it gets printed.
My understanding is that it’s both. Splitting the error message in the source code will cause the message that is printed to be on multiple lines therefore making filtering logs a bit annoying which is what I was showing in the example.
The same thing applies in the reverse case when grepping the source code for where the error message is.
The reason I didn’t put time into explaining that is because most modern logging implementations will have the file and line number etc where the error was thrown in the stack trace so you usually don’t need to grep the source code like you mentioned.
✅💯
I was confused by what you said about being able to split up lines by concatenating them. In your example, sure, the program output is still in one line so it's possible to use grep. But what if instead, you wanted to find where that error message was in the actual code? Now you can't find it, because it's split up...
It's a good practice to seperate the log messages strings from the main function by using char * variables.
I'd argue that searching for the message in the source is way more common than grepping a program output. You would usually see the log when inspecting the output after an error, then search for it to find out what went wrong in the code.
Excellent examples! Usually guidelines are difficult to convey because most examples are too trivia, simple and or unrealistic/ academic.
I disagree with 8 tabs example. I used to reading code 2 times more zoomed in than an example you've showed. This makes "too far to the right" mark go to, like, 4 levels of indentation. And also you've showed an example in Go which isn't an OOP-obsessed language. In C++ you'll get 3 levels of indentation just from method in a class in a namespace, and having 24 space nothing always at the start of the line seems bad for me.
Indeed.
The best advice I learned in coding is that all these programming tips, even languages themselves, are simply philosophies of some person, so don't make them sacred texts.
My laptop screen isn't thay wide so I also prefer 4 char identations even in a language like Go
Tabs with 4 chars configured
Only true answer
It is much easier to prohibit TABs in your VCS than configure every single editor and utility, given that some of them are 3-rd party and/or not configurable.
I 100% agree about comments, they're supposed to explain the "what" more than the "how". It's a good way to help future devs find bugs too.
How does Linus come into all this? Didn't hear him mentioned even once in the video.
Never heard him talking about these rules either
These are literally all from the linux kernel coding style guidelines which he wrote. www.kernel.org/doc/html/v4.10/process/coding-style.html
@@kantancodingouch
@@kantancoding you might want to make it clearer, and perhaps link the style document in the description.
@@maleldil1document.? What’s that?
while (*src++ = *desc++); nice buffer overflow ;-) Why not use some secure version strncpy(src, desc, lengthOfDesc);?
2 character indentations are for tiny todo apps. Any large code bases must use 4 characters for legibility
You only need 4 spaces if you have multiple indentation levels. Otherwise 2 will suffice. It's not about the size of the code as about how many indentation levels exist in the code
Off-topic question: What VS Code theme and font are you using? Looks good.
It looks like it's Gruvbox
I am also interested in the font
I usually write comments on the how and why when I come back to the code later and can't figure it out in a couple of minutes why I did it this way. I mean it's no big deal, there are additional lines that don't bother performance or disk space at all. An issue arises when it's more comments than lines of actual code, or something along those lines, when the code reading flow is interrupted by comments.
Agreed, I would rephrase the comment tip as "Don't write a long explanation comment if you can rewrite the code to explain itself, and be SHORTER than the long comment". Also assuming that rewriting the code to be longer doesn't increase performance cost. Sometimes smart one-liners aren't there just for the sake of being shorter, but to actually do something in a more performant way.
Hm. I have to disagree with your last point. It is far more useful to describe the "why" rather than the "what". The "what" should be readily obvious if you wrote the code correctly.
Code should be consistently fornatted
Code should be commented
Code should be concise.
Consistency, definitely.. the others deserve more explanation :)
Code should work
I actually prefer to measure code indentation in pixels because ...
What did you use for the nice code animations?
As unreadable as it is, that while loop is pretty genius though, I didn't know assignments return the read/written value like that.
Tabs depend on the language. For example, it's virtually impossible to code java with 8 space tabs as it is all nested scopes, inner classes and so on. Languages like rust with his pattern matching let you have far fewer nested or changed if statements.
Where is Linus other than in the thumbnail?
He's literally everywhere since every single one of these are from the linux kernel coding style guidelines which he wrote. www.kernel.org/doc/html/v4.10/process/coding-style.html
would you take a look at bsd kernel guidelines?
by bsd i meant freebsd
Nicely presented!
Thanks! And thanks for watching :)
@@kantancoding My pleasure, I write tutorials so I appreciate your work.
2:35 yandere dev moment
Undertale too
That's how real programmers code, sorry to break it to you, script kiddie
What about comments of "i don't know why this piece of code works. DO NOT REMOVE!".
aw man, i use different indentations for different languages. i follow the standards. for python, i use 4. for bash, i use 2. for c, i use 8. but it does not really matter. just go to vimrc and change tabstop and shiftwidth and remove expandtab. your identation will automatically update. you might have to :retab if you were using expandtab before. if someone else gives you a project, change your tabstop and shiftwidth to match the indentation of that person's project. if they're using spaces, set expandtab. match your vimrc settings with that project's settings so that everything is uniform and consistent and easy. if youre working on multiple projects with different indentation levels.... then..... if theyre different languages, autocmd will be fine. if theyre the same language, then..... if you know vim, you'll figure it out.
Good points :)
I didn't know the defualt is 8 in c.
@@luizAugustoll maybe it was 20 years ago. I looked it up today and most people prefer 4 in C today. i don't remember which standard i read, whether it was GNU C Standards or the C used in Linux development but one of the two said to use 8 spaces per tab. the default in vim is definitely 8 though. you'll have to add tabstop and shiftwidth to change it from the default to 4 spaces or 2 spaces.
I don't think you go far enough with your point about comments.
Don't tell me how, don't even tell me what. If I can't get a pretty good idea what some code is trying to achieve by reading it then it's probably no better than the code where the programmer felt the need to say how it works. The point where you need a comment is when you need to explain *why* it is the way it is. For example: "This string copy ends up being used in the render loop so if you don't squeeze literally every cycle the framerate is going to tank". Ok great, now I know that if I apply the code clean up then I need to ensure it optimises to the same code and also where I should probably go check performance before releasing it to production. The key part is that if the code looks out of place then the comment is there to try to convince me that doing it this way, as opposed to the way the rest of the codebase works, was the right thing. (Oh also, interface contracts should be documented as a matter of expectation management but that's not really a "comment" even if they use the same mechanism)
Also, the right number of spaces that an indent should be is whatever my auto-formatter is configured for and the correct way to get those number of spaces is to use the tab key. Also, if I want to go back to the previous level of indentation, I should be able to press backspace once while at the (indented) start of the line or sometimes shift-tab. To put this another way, the editor should act in every way shape and form as if Tab characters were being used but should only ever write the indent as space characters to the file system. I personally think that 2 characters is too little and 8 characters is probably too much but that's because i'm getting on in years and my eyes don't see as well as they used to but, ultimately, whatever is agreed upon as the auto-formatter settings is the correct value.
2:31 case of long function but acceptable
2:54 never try to explain how your code works in a comment
I don't like to have a big switch statements I usually prefer to have map and throw on null
uh, I'm not sure, do you guys think linux code is readable?
Ok, but where’s Linus?
He is talking about Linux kernel coding style
2:49 I would just use a dictionary in this case. Match one string to another and increment the required value.
Yeah, but I mean, it was intentionally made like that to illustrate an example of a long function that’s not complex. But thanks for the code review 😂
Come on, just set max nesting level in your linter config and it will enforce the rule no matter what tab size is. Really, all of the problems have already been solved by prettiers/formatters and linters.
The compiler should only get successfully linted code. The programmer must not avoid the linter.
2 spaces requires additional cognitive load to distinguish the nesting level.
4 spaces is a waste.
3 spaces is the *ONLY* correct answer.
The tab size should be individual. This can be accomplished by using tabs only, never spaces. End of discussion.
@@christernilsson1 The discussion is over only in fantasies. In the real world, tabs result in endless problems. There's a reason well-intentioned projects start off with tabs and switch to spaces but never the other way around.
@@DemPilafian please list the reasons. Here are mine: tabs are easier to insert and delete. Tabs takes less space. Tab width can be individualized. A company can change the standard from four to three spaces with a keystroke. And the main reason: there is nothing left to discuss.
@@christernilsson1 Tabs are theoretically better than spaces in every way. In practice, however, tabs are a mess.
1) Web pages and command line tools display tabs with ridiculous amounts of space.
2) Indentation and alignment are different, and alignment requires spaces which get destroyed by tabs.
3) For whatever weird reason, experienced smart developers occasionally submit pull requests with some indentation as spaces instead of tabs (the reverse does not happen).
The real world doesn’t care that tabs are theoretically superior. Engineering managers get tired of tabs interfering with code diffs.
@@DemPilafian Copying indented code from different ai:s and other sources will suffer from having different amount of spaces. All tools should be configurable, like VS Code.
0.24 it's the one with 4 spaces
someone else who uses agave nf, nice
5 character tabs.
First of all, it's not actually funny when Linus says nasty things about **anyone who writes code in even a slightly different style then he does** and it's not actually funny when you parrot it, either. He's been working on his attitude in recent years, because he understands how it has hurt the Linux community. You should participate in that reformation.
Second of all, code styles developed in kernel code in C have a completely different set of requirements than userspace code. Any attempted application of one style to the other should be taken with a massive grain of salt.
Third, use your IDE to add blank indent markers and they will be easy to see regardless of their width.
1 char is plenty
If you use a beautifier, there won’t be any problems. Just make sure same settings are used and run it before before you commit and make sure it compiles.
If only it were that simple 🫠
@ well, it solves many problems. If you don’t like tabs or something, just let it beautify the code to what you like and then beautify back when you check in. That’s what I liked about vb6. Having said that, there were those that wrote horrible code. My c++ code called vb6 code which was very good for what we wanted.
@ I should mention some things I really don’t like which are not solved. I really dislike code that is written such that it’s difficult to debug. Don’t use one line to write code that does two things and no nested functions!!. A colleague of mine had a switch statement where only a few cases were considered and there was no default which he claimed would never happen. I did introduce a default and it didn’t take long before it did much to his surprise.
I love ur videos 🥰🥰🥰
I watch all commercials too😁❣️
My code style never will be beautiful I know
funct(abc: xyz) { return }
funct(abc: xyz) {
return
}
funct(
abc: xyz,
klm: nop
)
{
return
}
Honestly don't think smart code affects readability, if people can't understand a regular function without max 3 lines of hints, it's really a skill issue on their side, unsmarting you code for people who have skill issues is some really unnecessary work. Not being mean just being real, there is nothing wrong with coding smarter. With all the LLMs going on understanding code shouldn't be a problem.
Not sure what you mean by “smart” code here. To me, “smart” code is simple.
Clever code is not useful for work. Not readable in one look. Other devs should be able to understand your code clearly for them to update it with confidence.
I am a tabSize: 3 user
blasphemy
func doSomething(animalType string) {
if _, exists := animalCounts[animalType]; exists {
animalCounts[animalType]++
}
}
It actually does
animal -> Animal
(First letter capitalisation)
if Animal[0] > 'Z'
Animal[0] += ('A' - 'a');
The lazy C way. Python is just toHigher()
Then if exist.
8 char is shit. Because good variable names aren't abreviated.
So the single
if ( LongAssVariableName > SomeOtherVariable && LongAssVariableName < TheWidthOfYourMom.InCentimeters() ) { ... } will be too much to the right.
Also, Im shit language like Java where everything is inside a class... Thats 1 less Identation.
So you maybe only like scripting languages, because functions as entry point is really important because you can't run code all over the place. So is Java, it just use classes instead, not really different. The C entry point must be a function and called main for example, allow the C runtime to do things before run, even assembly need an entry point.
tab tab
Linus-Rule 0: Insult people that are not your opponion.
0:45 let's cut to the chase. How are you going to deal with html and json files then? Scrolling left snd right 5 times a second?
Having preferences is fine, but claiming they indicate good or bad behavior (as in bad programming habits) is pure nonsense. They're just conventions, and the only downside is they don't work in the outside world. But within a personal project, or a team which agrees upon those conventions, there is not right or wrong style.
There is no HTML or JSON in the Linux kernel source code. 98.3% C, 0.7% assembly, and it just goes down from there.
Hmm, JSON isn’t code so I don’t really think these rules apply there. And admittedly, I don’t care enough about HTML to go down that rabbit hole 😂
you shouldn't be using HTML or JSON. They're both mistakes made up to solve problems that don't exist
Regardless what you think about these things and whether they are up to the task they're allegedly made to solve, they are still standards in the industry. Whether I, you or they like it or not, they (amd other things you don't like in the industry) are a reality that you, I and he will have to adapt to at some point, at least if we were to engage with the wider audience and teams we're not with at the moment.
Suppose you're a twch company, need tech workforce, preferably in C, but the entire workforce is too dumb and can only code in [choose a language so that I don't offend you unnecessarily]. And suppose you've been looking desperately for a C programmer for 5 years, and you can't sustain your company anymore (i.e., the ugly reality that json and html are bad solutions and need be disposed of). Do you bet on the utopian programmer that may (i.e., the future in which there would be no json or html, which are the bad inventions the industry adopts today) never come, or adapt to reality, as harsh and ugly it is, and try to make with ehat you got, in the tech workforce market?
I don't care if json is the worst thing in the world in this regard. What my point is about, is whther you liked it or not, you have to live with it, and adapt, as long as it is going to be the reality for the foreseeable future.
I haven't worked with html or json much, so I'm not dying on defending this hill, and have no dog in this fight. I am just concerned this self-obsessed attitude still lingers in this community.
But who am I to envision a society that deviates from normal human behavior? People were, and will ever be believing the sun and the entire universe revolve around their thick skulls.
Bit sorry to offend you, and I know I'm just a commenter and you are the one who did the work and made the content, but just have some humility.
@@kantancoding😂
Argument falls apart a bit in the context of OO-based UI toolkits where nesting of components is expected to be deep. Yes, one can break apart monolithic components into smaller ones, but even some of the smallest can have a significant depth to their tree.
@3:45 I call bullshit. If someone can't understand basic C theyve no business being in the code. I'd say your restructured code is harder to understand.... I'd be worried you wrote it like that for some obscure case I'm missing.
Combining multiple writes and a read into a condition is not "basic c"
Fourth ban innocent devs because their nationality ...
that comes from above
@@yjlom SO HE SHOULD HAVE HAD NO ISSUE TELLING THE TRITH ABOUT IT INSTEAD OF HIDING LIKE A COWARD... WITH THE BAN LINUS GET THE VILLAIN STIGMA NOW ...
Weren't banned, just were removed from the ability to sign off on their own code commits because of increasing geopolitical tensions. Believe me, it's safer for everyone involved when they can't be forced to put a backdoor in Linux.