> 8:15 whatever the guideline in your company is, it help you read through the code faster. No method may be shorter than 200 lines. Every method should take at least 15 parameters. Variable names should use aLtErNaTiNg CaPs. Not. Obviously if guideline X makes the code more readable, the guideline "avoid X at all costs" makes the code less readable (if followed). So the guidelines don't make the code more readable no matter what they are. They have to say specific good things in order to make the code better. Duh. But why is he saying that in effect the contents don't matter? In some areas, consistency increases readability all by itself. If you always get food after you hear a bell ring, the world is predictable. If a method does a network call if and only if its name starts with "fetch", the code is predictable. But making your methods consistently longer than 100 lines but shorter than 200 doesn't really accomplish anything useful on its own; knowing how far there is between the opening and closing curly brackets doesn't tell you anything about the stuff between them. My favorite degenerate trick is to turn an n-line function into one (n-1)-line function and one two-line function which calls the (n-1)-line function. Apply it enough times and all your functions can be two-liners. Heck, if you have left-to-right argument evaluation order, you can wrap the first line in a lambda and pass it as an argument (say, in the last position) to the next function, and pass the return value of these lambdas as the first argument when you go down the chain. That way, each old line gets executed in the right order, and every function is a one-liner. Obviously this is ludicrous. Longer functions would clearly be better than this nonsense. So there's an upward pressure on method length when you optimize for readability. [There's also a downward pressure. If you know the line length at which the pressures balance out, on average, across all the code I will write in the future, I want to know how you know.]
am I the only one that is annoyed by the first example that getSessions is a getter but does not return a value? One thing I do know about coding is that the naming of the similar classes should be consistent. So every method starting with getXXX returns a value, and every method starting with isXXX returns a boolean.
I find it irritating when so many of the examples of what not to do are unrealistic straw man examples. I can't say I have ever worked in an environment where people intentionally make misspellings in their code, or make comments that repeat what the code says in the way that the presenter was ridiculing here ("//if", "//endif"). In explaining the value of comments, He would do better to emphasize more positive examples of code comments that provide context that the code otherwise would not.
Thanks for the feedback. I've seen all of these many times, but I appreciate the feedback and like the idea of showing some other contexts too. I do that in some longer versions of this talk that I give. Thanks
Thanks for the reply, I guess I should feel fortunate that I haven't had those bad experiences. My usual frustration is that the code is not commented enough, perhaps because the developer believes they write "self-commenting" code. I'm all for naming things appropriately, but comments can convey things that code cannot -- e.g. intent and rationale, high-level explanation. Those are the sort of things would be great to see as examples of how to do it right.
@Ryan Not always, a comment could be a resume of few lines of code which are understandable when you read them, and also depends on the expertise of the developer that is reading it. Comment are not bad beside self or not-self explaining code. What you wrote looks to me more like a justification to don't write comments ;)
Some idiots at my old work used a utf-8 house for an SCSS mixin library. Every time you needed to refer to a mixin you had to manually find the character then copy and paste it.
That bald man from Brazzers, he knows so much!
this guy always rock on his presentations
Great performance, make readable code is the best practice that every developer should follow. Keep calm and code!
> 8:15 whatever the guideline in your company is, it help you read through the code faster.
No method may be shorter than 200 lines.
Every method should take at least 15 parameters.
Variable names should use aLtErNaTiNg CaPs.
Not.
Obviously if guideline X makes the code more readable, the guideline "avoid X at all costs" makes the code less readable (if followed). So the guidelines don't make the code more readable no matter what they are. They have to say specific good things in order to make the code better. Duh. But why is he saying that in effect the contents don't matter?
In some areas, consistency increases readability all by itself. If you always get food after you hear a bell ring, the world is predictable. If a method does a network call if and only if its name starts with "fetch", the code is predictable. But making your methods consistently longer than 100 lines but shorter than 200 doesn't really accomplish anything useful on its own; knowing how far there is between the opening and closing curly brackets doesn't tell you anything about the stuff between them.
My favorite degenerate trick is to turn an n-line function into one (n-1)-line function and one two-line function which calls the (n-1)-line function. Apply it enough times and all your functions can be two-liners. Heck, if you have left-to-right argument evaluation order, you can wrap the first line in a lambda and pass it as an argument (say, in the last position) to the next function, and pass the return value of these lambdas as the first argument when you go down the chain. That way, each old line gets executed in the right order, and every function is a one-liner. Obviously this is ludicrous. Longer functions would clearly be better than this nonsense. So there's an upward pressure on method length when you optimize for readability. [There's also a downward pressure. If you know the line length at which the pressures balance out, on average, across all the code I will write in the future, I want to know how you know.]
I use your repositories all the time. Thank you !
thanks!
Resources:
Style Guide - jpapa.me/ng-guide
VS Code - aka.ms/codeit
Angular Essentials - aka.ms/ng-essentials
Winter Theme - aka.ms/jp-winter
Great talk John Papa and i must say that i totally agree with all.
thanks
Great talk for newbies. John covered majority of well-known truths.
Great talk John Papa!
thanks!
Nice presentation. I totally liked it
Learned a lot with fun, Thanks.
Great to hear, thanks for watching!
#Awesome talk john papa, Like!
Thank you!
you are my idol John Papa
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
hehe ... exactly!
I think this is an old joke. Older then the first mainframe
Good presentation, thanks.
you're welcome. thanks for watching
It would be nice if i had the time for that
Thank you. That was great for me :)
you're welcome
11:49 should actually read like "Comments don't have place in the code"
am I the only one that is annoyed by the first example that getSessions is a getter but does not return a value? One thing I do know about coding is that the naming of the similar classes should be consistent. So every method starting with getXXX returns a value, and every method starting with isXXX returns a boolean.
Love you Sir !! 😊
On papa we trust
What font did he use at 1:22?
Operator Mono
now I just need to learn to code
John Papa === LIKE
Thank you!
a function can also lie. it's what we call "bug" or "crash".
Readable angular JavaScript?
Who the hell nests ternary statements?
I find it irritating when so many of the examples of what not to do are unrealistic straw man examples. I can't say I have ever worked in an environment where people intentionally make misspellings in their code, or make comments that repeat what the code says in the way that the presenter was ridiculing here ("//if", "//endif"). In explaining the value of comments, He would do better to emphasize more positive examples of code comments that provide context that the code otherwise would not.
Thanks for the feedback. I've seen all of these many times, but I appreciate the feedback and like the idea of showing some other contexts too. I do that in some longer versions of this talk that I give. Thanks
Thanks for the reply, I guess I should feel fortunate that I haven't had those bad experiences. My usual frustration is that the code is not commented enough, perhaps because the developer believes they write "self-commenting" code. I'm all for naming things appropriately, but comments can convey things that code cannot -- e.g. intent and rationale, high-level explanation. Those are the sort of things would be great to see as examples of how to do it right.
@Ryan Not always, a comment could be a resume of few lines of code which are understandable when you read them, and also depends on the expertise of the developer that is reading it. Comment are not bad beside self or not-self explaining code. What you wrote looks to me more like a justification to don't write comments ;)
Pros and cons of comment discussed here, from the book "Code Complete": flylib.com/books/en/2.823.1.274/1/
Nice Font @1:34 can I have that for free? =D
valideight? Seriously ? And they were laughing at it. How old were these developers? 5?
Some idiots at my old work used a utf-8 house for an SCSS mixin library. Every time you needed to refer to a mixin you had to manually find the character then copy and paste it.
Supurb!
John Papa looks like Vin Diesel
Once i've seen a comment :
It's ugly. i know keep reading
Brazzers
This video has spoiler of the key moment from Star Wars :) Be aware
I'm the guy that haven't watched any movie of star wars and don't care about it.
el pelon de brazzers
John Papa forgot one thing here. To give regards to Robert C. Martin...
I credited "Uncle Bob" in a slide, one of his quotes (early)