10 Tips For Clean Code

What is the clean code? In this talk the speaker will provide some answers to this question, and introduce you to 10 good habits that will help keep your code clean.
EVENT: Wordcamp US, 2016
SPEAKER: Michael Toppa
CREDITS: This is a repost of the original video published on WordPress KZbin channel (kzbin.info/door/pJf..., which was uploaded with the Creative Commons Attribution license (reuse allowed).
ORIGINAL SOURCE: • Michael Toppa: 10 Tips...

[@jessiechan7629]

#1: You're responsible for code quality. #2: Use meaningful names. #3: Write code that expresses intent. #4: Code should speak for itself. Less comments = less maintenance. #5: Leave the code better than you found it. #6: Single-responsibility code. i.e function does 1 thing well. Less arguments = better function. classes: most methods use most of the class' properties. #7: Tests (TDD). #8: Work on big picture skeleton, then fill in the details later (interface first, implementation later). #9: Independent components that can be used in different places. #10: Master your craft. How tf does this comment get so many likes? I'm just paraphrasing what the video says LUUL.

[@kensmith5694]

I disagree about breaking up classed just because a method doesn't use all the properties. This is a sure way to end up with a huge surface area on your code that the next guy has to paw through to figure out what the heck is going wrong with the zillion wiggly interacting classes. I somewhat disagree with the "less comments". You shouldn't be commenting things like "I am adding 2 numbers". You should be commenting things like "This uses sqrt() so negative values of X are not allowed"

[@kensmith5694]

rymonator: The way he said it Circle.SetRadius(R) Circle.SetLocation(X,Y) Circle.SetColor(RGB) would have to be broken up into 3 classes if you followed the rule as stated so it was a case of overboard.

[@dusanp5160]

nope. he was talking about class properties, not different arguments for methods. but we still should think twice before split something. end with 100 classes for a really simple project is too much.

[@jessiechan7629]

Yeah I think comments should explain the "why", the intention behind the code, and not what it does.

[@blargo]

Ken, that's not at all what he said. The quote is, "if you have one subset of the methods using half of the properties, and another subset using the other half, that's a good candidate to split the class". Of course, these are just tips, not hard-and-fast rules. So you'd use your own judgment on whether to actually split the class.

[@vaughn8844]

Mr. Toppa's Ten Tips with time markers: #1: You are responsible for the quality of your code (2:31) #2: Use meaningful names (3:30) #3: Write code that expresses intent (4:23) #4: Code should speak for itself whenever possible (4:58) #5: Leave the code better than you found it (6:17) #6: Single-responsibility principle (7:05) #7: Write Tests (8:37) #8: Work in short cycles: incremental and iterative (9:34) -- skipped #9: Independent Architecture (9:36) #10: Practice, Practice, Practice (10:40)

[@Tymon0000]

To get the cleanest code you have to wipe your screen.

[@kensmith5694]

Use a Q-tip to get into the corners

[@kensmith5694]

Buffer = a cloth used to wipe and polish the screen. Range Checking = making sure you didn't leave the stove on. Underflow = water that leaks out the bottom of your water cooled PC.

[@homedevise8025]

😂 😂

[@wickedlyann9514]

....but still, what you're really getting is just a clean screen...clean code? maybe not

[@russianroomba9948]

@@wickedlyann9514 r/wooosh

[@superstringcheese]

99% of programmers will like this video, and then go back to writing dirty code, because their project is always unusually justified for being quick and dirty.

[@TheSETJ]

It's because it's not easy to translate theory to practice. Knowing tips and best practices, don't make you better until you know how to implement based on them.

[@waitatantonyng5272]

It actually doesn't take much time to write cleaner code, if you have the "clean code" mindset from the very beginning. On the contrary, the price you will pay later would be much higher for writing dirty code.

[@HumbertoRincon]

The conference put the seed. Now everyone must feed it, at your own pace.

[@moofymoo]

if you get bonuses for shipping in time with good enough dirty code or unleasant meetings with management because you were trying to write best possible code you can write.. what you will choose, at age 20, 30, 40?

[@Assassunn]

​@@TheSETJ it's just a mindset, code can LOOK elegant, just with indentation, then with conventions / norms, and then with generic codes, small, readable code. It can give you headaches, and have a steep learning curve, but it's all a matter of practicing then it's like coding normal, but it decreases : error probability, maintenance time, architecture thinking, and teamworker's headaches. Seriously, if I have to maintain a dirty code from a teamworker, I'll complain within a hour, then eventually ask for a better salary, because it simply makes it harder/longer for you to work on, but also less enjoyable.

[@yuriymatso]

Love the analogy with the doctors and accountants! Professional standards are definitely important

[@lucasterable]

The content of this talk - as well as those two analogies - is entirely taken from Rober C. Martin's opus. Read his books.

[@STFU665]

@@lucasterable I'm with you, you really need to read these books, they are mindblowing.

[@aminehamou4980]

I would have loved to hear him explain number 8.

[@cardmstr]

clean talk about clean code. Love when people are concise and to the point lol great notes :)

[@fortuneflux]

O.M.G, my entire company needs to watch this. I spend 50% just trying to work out and more often than not rewrite other people's code.

[@stevenspithaler1979]

Job security

[@itech40]

+Devonly Share it with them!

[@MecchaKakkoi]

Get them to read The Clean Coder by Bob Martin. Most of this talk is lifted from there.

[@SheeceGardazi]

I love this channel, they always find really cool talks and ALWAYS give due CREDITS. Thank you so much for that.

[@jekabskarklins]

All this is heard before many times, but I must say you explain it really well and interesting.

[@arpitparmar2121]

Watching this video after long time and still it taught me that i was not following the single resposibility code/functions! Thank you again Coding Tech for this awesome video gonna share it now so that others can learn from this too :)

[@seanlee566]

This is the best video on programming I have watched. I wish I saw this when I started out 3 years ago.

[@Iwillownyouandbehappy]

I was asking for presentation about this and here it is. Thanks Coding Tech!

[@AtomkeySinclair]

That was a really good talk and I enjoyed it. I wished he had ventured into program management where teams are involved. Of course his #1 rule is pertinent from 'my' point of view always. I both want and need my code to be self explanatory and as elegant as possible. But style comes into that and sometimes styles collide horribly. I've found that working in teams takes an initial time period of annealing style across the development atmosphere. In my case I spend time with each member of the team coding together at the same time and same place - right next to each other. Even taking turns at the keyboard. This is especially helpful in a group meeting when a particular aspect of the software needs greater attention. His comments on how the language forms a prose is excellent (vars as nouns, etc). And that style aspect determines the tone of the message so to speak. If one person is composing a melody and another is writing heavy metal, it just doesn't jive.

[@ruixue6955]

2:31 #1 You're responsible for the quality of your code 3:35 #2 Using meaningful names 4:12 great code should look like well written prose 4:26 #3 Write code that expresses intent 5:12 #4 comments are often lies waiting to happen, code should speak for itself 6:20 #5 the Boy Scout Rule 7:05 #6 Single Responsibility Principle 8:38 #7 write tests 9:16 unit tests 9:36 #9 independent architecture 10:41 #10 practice

[@lucasterable]

Fun fact: writing clean code actually saves you time IMMEDIATELY

[@g3mint446]

If you know how to, ofc. Writing doesnt take a lot of time, research does. Its all relative.

[@pav7611]

Really needed this video. I thought before I move deeper into writing more code, I should take a pause and clean up the existing code; even thou its tedious and boring to do so, where instead I could be coding.

[@suzesiviter6083]

So true about comments, you end up neglecting comments as you update code due to time constrictions, better to use them only when you are very sure the code will not need updating.

[@kylekoivukangas801]

I agree that rushing is actually somewhat counter-intuitive in that it makes things take longer because you take shortcuts and make mistakes and you end up having to go back and fix them. This applies to most things in life, not just coding..

Thx for sharing, great talk.

[@minimalistapps8299]

What a great presentation!

[@FilmonGEMZ]

Great talk thanks for sharing!!!

[@Azlorn]

I support and/or condone this video.

[@bigpapa2845]

I was never taught what "meaningful names" truly meant until I took a course in Objective C. No comments needed... If the name of a function is VERY descriptive.

[@i_am_ashutosh]

Amazing. Really helpful. Thanks

[@nelsonsanchez699]

I really disagree with #4 about writing less comments. I do however agree with how code should speak for itself, but on the topic of comments, documentation is one of the most important things you should do when writing clean code. Document everything, and as much as possible. Documentation actually makes your project more maintainable, not less. When you're presented with a task to fix something, you want to make sure that you're in the right place, and while yes one way of doing that is by reading through thousands of lines of code (which can be a nightmare if you're dealing with code that was written poorly by someone), another way is by reading the comments which tell you exactly what the developer was thinking when he wrote the code. The purpose of documentation is that you're making sure that when someone see's your code, they'll be able to know what you were thinking when writing it, this can help quickly assess any issues, and fix it faster. This can also help newer people in the project learn from your code, as it'll give people an idea of how you solved a problem differently than they would have. They would also know what the code was `intended` to do, before seeing what the code `actually` does and that's really valuable when trying to fix problems. Lastly, documentation is really important even if you're not working with teams. As developers we're always learning something new, the way we write code today, isn't going to be the same as the way we would write it a year from now. Now imagine creating a project, working on it for 6 months, and then for whatever reason not looking at the code again for a while (maybe you've been working on other projects). Immediately you'd know what every function was intended to do and what your thought process was when writing it, because it would be documented. And if for whatever reason you decide to introduce different maintainers, it would be a lot less of a nightmare for them.

[@suzesiviter6083]

) depends how complex the project is and how strict your deadlines are, if you make a lot of changes then have to change comments it really slows things down. His point is, use good naming practices first and then use comments as a backup, don't just comment and leave variable definitions ambiguous.

[@GatorDunnAZ]

When I find myself wanting or needing to write a comment in my code it's usually time to step back and refactor and make the code more readable on its own.

[@suzesiviter6083]

@@GatorDunnAZ Exactly the same, I spend more times editing variable names or even a few more lines of code just to make it much easier to read.

[@suzesiviter6083]

@@GatorDunnAZ Say you have a function call: Y =sin (180); I would change this call by copying the original function header and assigning: $degees=180; Y=Sin(Degrees); One extra line of code, but now you know what the variable is...obviously this is just a simplistic example).

[@markstein2845]

I disagree

[@jincyquones]

ｃｌｅａｎ ｃｏｄｅ ｉｓ ｂｅａｕｔｉｆｕｌ ｃｏｄｅ

[@potatolord7319]

b i g letters i s g o o d le t t e r s

[@Gamerweazel]

Abe Lincoln teaching me coding? Yes please!

[@HumbertoRincon]

Or even David Copperfield maybe?

[@TokyoXtreme]

@@HumbertoRincon Norman Bates (Anthony Perkins)

[@MrClassicmetal]

It's Steve Vai.

[@AeroPR]

Great talk. Would have loved for it to be longer. For those new to this topic looking for for more depth, look at the Clean Code talks here and books by Uncle Bob Martin

[@divyanshu30gupta]

I love listening to him

[@mariuspet89]

Love this guy!!

[@meqdaddev3100]

Great and brief speech

[@sebpatu]

You were wondefull in code quantum!

[@AndiSyafrianda]

2020 and this talk still related now

[@kcoleinvelos]

Agreed on all except the Boy Scout rule. To improve the understandability of code, you must fully understand the code. Under a deadline, that can be dangerous. Worse, those changes are almost by definition out of the scope of requirements, which can mean they're never acceptance tested. IMHO, this is a great use for a //TODO. Make a note about the weird code and what you believe it's trying to do. Come back when you have time, re-examine and make sure you agree with your past self, then make the improvements.

[@RobertHolzapfel]

Although this speech now has a bit an age, but the messages are still worthy. Michael I loved most the rule #1 especially your explanation of being "expert" and "professional". No one wouldn't respect a doctor or a lawyer working sloppy. So it is up to us developers to stand up for our quality.

[@robolson135]

Brother have you ever had a doctor write you a prescription? Sheeeeeeeesh

[@RobertHolzapfel]

@@robolson135 I don't get your point. And I don't understand, what the sound "Sheee..." stands for. 🤔

[@RobertHolzapfel]

​@@robolson135: I don't get your point and I don't understand what the sound "She..." stands for. 🤔

[@robolson135]

Lol sheesh is a slang similar to wow and the comment is responding to the claim of no one would respect doctors if they work sloppy but meanwhile you can't read read a single thing they said!

[@abdullahalsabbagh]

Thank you for the tips

[@aRookieProgrammer]

I like the crisp in your voice

[@alexandros-markovits]

Nice presentation

[@tarasov9794]

A clean presentation.

[@hammer158]

A clean comment.

[@arifikhsanudin9724]

@@hammer158 a clean reply.

[@ex0stasis72]

This is basically what they told me on the first day in my first freshman programming course at college.

[@markstein2845]

Teaching clean code practices in the first day of the coding school is like teaching about steroids in the first day at the gym.

[@adtc]

I've never practiced boy scout rule because other programmers or the technical manager could be very protective of the code that's outside my task's concern, especially if they perceive it a threat to the coded system's stability to alter the code without any need for altering it.

[@roazr9736]

Great tips!!!!

[@PierreDole]

Thank you.

[@marcelobaus]

Very clear.

[@WyvernDotRed]

I'm going to take these tips into consideration when I start my horribly ambitious project I want to start!

[@tangomuzi]

Impressive. So dense so to the point. He is serious. He is there to to teach not to show off.

[@im.empimp]

#8 was to "Work in short cycles: incremental and iterative" - stop the video at @9:35 to see the slide

[@strohtaler4698]

well, I've seen/heard "I am running out of time, I'm going to move a little faster, lets skip ... " and make dirty code - isn't lack of time the problem?

[@boscorohan]

@@strohtaler4698 1/2 lack of time is the problem. But having clean code saves you a lot of time in testing and future proofing your design. It's actually counter-intuitive to many, think of it as an exponential function where it takes a lot of time than usual at the beginning

[@boscorohan]

@@strohtaler4698 2/2 but adding features is relatively easy and very fast once you have a strong architecture and clean code. In fact new possibilities open up for features that couldn't be conceived if it weren't neatly structured.

[@mikecarr4475]

Bosco Jacinto well said. Having worked in a dev shop before, i can recall that lack of time led to lack of solid infrastructure and clean code. Implementing new features was a pain, and refactors were required almost every story. Good learning experience

[@PankajNikam]

I wish the speaker had more time to elaborate. It would certainly help the new comers to the amazing world of software development. Most of the experienced programmers may relate and totally understand what he has to say, however new comers may find it difficult. If you are a newbie in programming, please please read "Clean Code" by Robert C Martin along with what you are learning. I wish in my grad days I had this book :(

[@santhoshs1798]

I am working with God. Before 3 trillions of years we coded this man. Yeah it's a great success.

[@oufcena5092]

aijs.rocks/

[@dlbattle100]

It's always surprised me that the wisdom about "meaningful names" in programming is the exact opposite of the thinking in fields like physics and math. In those fields you are expected to use symbols that are as compact as possible in order to fit as much meaning as possible on the page.

[@leonetassinari6654]

David Battle actually abbreviations are never used unless they've been declared and defined previously. For example you'd say a force F is exerted on an object with mass m, provoking an accelertion a that is directly proportional to F and inversely proportional to m: a = F/m

[@dlbattle100]

Yes, but if you watch the video he explicitly recommends against doing things like that in programming. He (and pretty much everyone else who teaches programming) wants you to use long names every time. I have 25 years experience as a programmer, and I can tell you from bitter personal experience it is a bad idea. The math/physics convention of defining a short name once and then using it is much more practical.

[@leonetassinari6654]

David Battle I totally agree. I usually include a little legenda in my code to remember the meaning of variables and functions. Moreover I try to give everything abbreviated talking names like "int tDays" instead of "int time_elapsed_in_days". I don't know how readable it is, but it works fine for me.

[@RasmusSchultz]

David Battle it's a matter of balancing verbosity against readability - in the context of a given function or method, I tend to use single words, because names like number_of_days don't make the code very readable, it's too many words to visually parse for a person, it's too verbose. Likely a name like "days" is totally fine, if there are no other vars in the same scope counting days. The type hint should tell you it's a number, and words like "of" don't help at all, unless the var is a map (or other collection type) describing a relationship. It helps to think of code as something that describes the program's behavior to a person - like a recipe or a manual. Always optimize for people first, compilers or interpreters second, and never at the cost of complicating the code for a person :-)

[@timothymusson5040]

It works for you when your head is in that code. It doesn’t work for other people maintaining or bug hunting your code, and it doesn’t work for you when you come back to that code years later (unless you always work on that singular code base, or you have a very unique and special mind). Variable and function names should be as short as possible while leaving the code in an easy to read and understand state. That’s what we should optimize for, not absolute density of information.

[@VisualBRON]

When did Harry Shearer's "Principal Skinner" teach coding? T'was a good intro Sire! Can we have more please.

[@andre-barrett]

I learned a lot of these principles years ago and I'm a big advocate of all these approaches. Having coached and mentored countless software engineers in my 20+ year career I have actually seen developers benefit from these and other tips I share

[@Chelloh]

I love clean code.

[@angledcoathanger]

I’m assigned to refactoring at the moment and jeez I wish we did all these things.

[@moneyfish2490]

My team follows these tips! My game's code is very clean!

[@vickylance]

for how long is ur team following this?

[@moneyfish2490]

vignesh sivakumar roughly one year.

[@miguelduarte75]

What game you developing?

[@suzesiviter6083]

The other developers must be aching to cop their hands on your joystick.

[@hasankaraoglu5860]

While you are writing clean code, you shouldn't try to write excellent code. Excellent and clean code are different. Don't confuse them. Excellent code forces you to overengineering. And it is waste of time.

[@fahmiachmad7861]

Hasan KARAOĞLU sir, i'll more appreciate if you explain more about overengineering :)

[@gabriel_export]

@Hilbert França what he is saying is that there is always a more "efficient" or "elegant" way to write some code. But it normally takes you longer to accomplish that and for really no reason other than its the most "elegant" with little efficiency benefit. Instead of taking part in this overengineering, try to write clean code. Clean code is just easily readable and organized.

[@kevingonzalez-do2gd]

good video

[@immortalnub]

4:43 Why is that set method also a get method? This method is already doing one too many things. Remove the return statement from the method, then create a new method called get_numeric_thumbnail_size() that has the return statement. That's coding 101 right there.

[@nerd31415926535]

I think comments are essential at the method api for dynamically-typed and untyped languages. Otherwise you can end up with something like Microsoft's "Hungarian" variable names.

[@kensmith5694]

Yes, comments are important. They need to explain the why of the code more than the how. For example I bet few would know what this bit of bash script is for: X=0 Y=0 XF=1 YF=1 while (( $VALUE > 0 )) ; do TEMP=$(( $VALUE / 3 )) X=$(( $X + ($VALUE - 3 * $TEMP) * $XF )) XF=$(( $XF * 3 )) VALUE=$TEMP TEMP=$(( $VALUE / 2 )) Y=$(( $Y + ($VALUE - 2 * $TEMP) * $YF )) YF=$(( $YF * 2 )) VALUE=$TEMP done It is obvious what it does but far less so in the why anyone would need to do this,

[@MusicByJC]

You can by with a lot of comments if you name your functions and variables with good descriptive name. And when you do comment, explain why and what the function does not what the individual lines do.

[@iamtafara]

makes sense

[@deerajnayak9065]

super

[@ruthlessadmin]

So far, as a relatively new developer, what I notice more than anything is that it seems the entire industry does not understand object oriented programming. Everything winds up being a class, whether that bit of code represents a discrete logical object or not. It's like people think classes and methods are the namespace equivalent of directories and files....

[@holonaut]

do you have an example for the opposite of a discrete logical object?

[@georganatoly6646]

Also don't write state-full code unless you have to, keep the direction of data flow unidirectional as much as possible.

[@badbytes9644]

He took all this from Clean Code book!!

[@Walter_]

Anything for youtube ad revenue i guess.

[@RemiStardust]

Have you seen the movie 'Psycho'? Sure has a resemblance to Mr Bates!

[@norulesprateek]

number 8 was actually hidden : 'make sure you think your code ahead of time', so that you don't miss any important detail at the last minute.

[@Ateszika]

7:32 pandas has something like ~15 function arguments on average :D

[@nimeshganatra9932]

its from that book “clean code” isn’t it ?

[@MichelJung]

It makes me sad that these things even need to be told. To students, fine, but too many times the target audience is "senior" developers who are an embarassment to our industry.

[@ricardow9281]

Meh, I'm looking up video's as a 2nd year Software Engineering student to improve the cleanliness of my code. Found nothing new here. So most students wouldn't make these mistakes either I reckon.

[@g3mint446]

What he said about taking responsibility for the code is gonna stick with me. Be professional about it. One thing though. Clients might want new a new service set up in a day or two. And the apps value you don't know until its actually starting to sell. The point is be humble about your standards, it's not black and white. You dont get a quality burger ordering at McD. Weigh importance, scale and users, and decide if the time spent setting up tests and making it highly readable is worth the time. If you are constantly pulling excuses to write pretty bulletproof code. You will be costing everyone money. A complex specialcase feature for one stubborn pennywise customer is not worth arguing with ur manager over to spend 50% of the time optimizing. If you are competent enough to pull off great code architecture on the fly then by all means go ahead. As a programmer your job is to create value, not learning or researching cools stuff at the business expense. There is another time for that.

[@cipherxen2]

Bad example of #2 I found in some code. class MenuMasterDetailEntityClass { String menuMasterDetailEntityName; } class MenuMasterDetailDetailEntityClass { String menuMasterDetailDetailEntityName; } Second class is child of first class.

[@walidjabari4985]

:'(

[@markstein2845]

Hahahahahahahahaha unbelievable, one would rather be a writer than a programmer.

[@mvargasmoran]

not trying to say I know everything, but as the presenter said, go look for uncle bob martin, he even talks about some physics at the beginning of each presentation.

[@cozyrain410]

literally the book "Clean code"

[@JohnSkeel]

#4 less comments he said is controversial. Yep, it is. So, we go from "be professional, take the time you need to do it right" to "it takes to much time to write and maintain comments." Um. I used to be one of the cool kids who wrote little to no comments. I bought into the "code should document itself" theory. Hell, I was one of the guys preaching that back in the 90's. It's BS. After well over 200 large, professional projects I can say unequivacably that well commented code will save you time, a lot of time. Even when the project is brand new and you're in beta making last minute changes and bug fixes, quick scanning the comments to remind yourself why you did this thing 3 months ago instead of another can save you making a "fix" that breaks something else. And, two years later when you don't remember at all how the hell the code works, you can get back up to speed in a small fraction of the time it takes to read only code and work it out. I also disagree with the idea that comments can create a lie. It shows what the programmer thought he/she was doing, which may not be what is actually happening - what our presenter called the lie. If you're the guy coming in later trying to work out the problem, you can see "oh, he thought this returned x but it's y." I've gone from a few half-hearted and thoroughly obvious comments to detailed, almost every line comments. So, I'm not one of the cool kids anymore, but I get to go home at a regular time everyday and my stress level is way down.

[@snipdeath]

Exactly the opposite to your experience happened to me, so I agree that this topic is controversial.

[@markstein2845]

Usually I don't write comments to describe what a function does but I do write comments to describe why I implemented something in the function in a strange way. If my boss really wants a documentation on a method called getBalance from a class called Account saying /** get the balance of the current Account **/ I usually make my 11 and 13 years old children to do it for when I home.

[@pluraltest9242]

clean code is to a succinct sentence ; limit side-effects as much as possible and remove unused variables/methods get rid of bloat

[@MartinJohnZ]

This guy's shadow intrigues me.

[@EricSartor]

What I learned from reading these comments is that programmers do not agree on anything and are very confident. Especially regarding style conventions. Fuck it, just I'm just gunna write everything in all caps. ADDTWONUMBERSTOGETHERANDRETURNTHERESULT(FIRSTNUMBER, SECONDNUMBER) { return FIRST NUMBER + SECONDNUMBER; } PRINTANUMBERTOTHESCREEN(ADDTWONUMBERSTOGETHERANDRETURNTHERESULT(1, 2));

[@kensmith5694]

You failed to learn one other important point about programmers: All programmers think the other guy's code is really bad

[@matthewround9398]

Eric Sartor I

[@dariusdulskis1237]

You are rebel mate. Che Guevera of computer coding world :)))

[@nbamj88]

Initially, I thought this was a funeral 0_o The tone though...

[@guavabean2969]

Having a community where you can ask questions & share your wins and struggles is super important to a healthy & happy remote work life. Check out the GUAVABEAN Freelancer Group 👉 facebook.com/groups/guavabean/

[@Irzani938]

Planning to rewrite ci3 into ci4

[@Chandral]

Does anyone else also feel like working under this man as a mentee?

[@ChrisSwafford1]

Well. . . in a perfect world. Being asked to perform a job requiring hours is now expected much sooner.

[@oscarwang7920]

Naming a variable is one of the hardest thing to do

[@LittleMopeHead]

Clean code also include consistency.

[@suzesiviter6083]

Very true, using say var string for single text manipulation in multiple functions means you need less concentration to debug.

[@beto.aveiga]

You can't improve code or refactor without proper testing. Hence, you can't write quality code without testing. Do NOT underestimate testing. You are welcome :)

[@jackflash9123]

Yeah, but Client: Do project fast for little money. Me: No then its bad code. Client: Okay, I find someone else. Then I die because no more food.

[@kiljeaden767]

What ever. Warn them if they keep asking for quick development then it's what they wanted and you warned them

[@yksnidog]

Client: Do the breaks for my car. But be fast. And does it cost much? Me: No. I just take them out of service... Or saying it in other words: Be the professional you want to be. Don't cry cause there could be a plumber coding it for free. If a plumbers code is doing the job - maybe you misunderstood the assignment... In all other cases they will come back when he failed. And do not let them out cheap.

[@paulisaris]

Why are you just reading the chapter titles of the "Clean Code" book? :P

[@perfectionbox]

And avoid premature optimization

[@igor-ld8qm]

i'm just looking at my code rn and im dying on the inside

[@dancostinel5829]

I would write it like: public function setNumericThumbnailSize(string $requestedSize = 'xmall') { if (array_key_exists($requestedSize, $this->thumbnailSizesMap)) { return $this->numericThumbnailSizesMaps[$requestedSize]; } throw new Exception(__('invalid thumbnail size requested', 'shashin')); }

[@sergioveron6964]

im new in programming , i can to learn python?

[@teknoglot]

You can learn any language if you try, but python is often regarded as a simple one that enforces somewhat decent formatting principles. Check out codeacademy.com or similar sites.

[@fleecemaster]

No, you are not allowed to learn Python. I asked the Python council and they rejected you. Sorry.

[@Ghorda9]

@Flee Don't be an arse, just because you don't like python.

[@sergioveron6964]

idk programing, im beginner.

[@fleecemaster]

Ghorda9, who said I didn't like Python? I just told you I have a seat on the Python council. Due to your lack of faith we have decided to also ban you from the Python community. I'm sorry, please return your programming gloves and Python hat to your nearest Python guild.

[@sidhantpatra9213]

Real life Richard Hendricks

[@robertii8373]

As a electronic musician I am nervously peaking into this world of computer programming & people like Michael Toppa with their lovely teaching method and vibe is making it seem plausible that I might be able to do some stuff and even contribute to the sector one-day - Thanks very much !!

[@sirving1297]

ya ok. but tabs or spaces? cuddled else or nah?

[@AadidevSooknananNXS]

Begins at 2:34

[@shahbazsheikh3545]

He skipped #8 (Incremental, Iterative). Wanted to know more on that :(

[@JacobJNilsson]

I would guess he means that you shouldn't try to do it all at once, or make it perfect at the first try. Do little at a time, get the basics working then improve a little then improve again and so forth.

[@shahbazsheikh3545]

That makes sense. Thanks.

[@leoingson]

My take from the pics: Incremental: Make the most basic feature work (= test it). Add a little, make it work, etc. Iterative: Code down the concept (interfaces..). Stuff it with some inplementation. Implement more details, etc.

[@shahbazsheikh3545]

Yeah that sounds about right. Thanks for clarifying.

[@Ultrajuiced]

TDD e.g. promotes this pretty well, doesn't it?

[@rahilahmad1980]

#8 has coding and life lessons 🥲

[@Darival92]

where i work they dont let me use more than 80 columns in my documents T.T, the struggle

[@markstein2845]

I usually don't use more than 60 columns.

[@eset3649]

so pretty much common sense