Clean Code vs Preference

  Рет қаралды 51,067

Traversy Media

Traversy Media

Күн бұрын

Let's talk about the phrase "clean code" and how it can be pretty subjective and a lot of it comes down to preference.
⭐ Check out Agora!
bit.ly/3bLM8Iu
🐥 Clean Code Tweet:
/ 1577706658943344641
💻 All Courses:
traversymedia.com
💖 Show Support
Patreon: / traversymedia
PayPal: paypal.me/traversymedia
👇 Follow Traversy Media On Social Media:
Twitter: / traversymedia
Instagram: / traversymedia
Linkedin: / bradtraversy

Пікірлер: 236
@ansonthedev
@ansonthedev Жыл бұрын
I personally find the term "Clean Code" as a gatekeeper from developers to actually write any code at all. From personal experience, whenever I feel stressed over writing "clean code", I find myself writing almost no code. But when I do at least write something, I know I can always re-factor it later to make it more "cleaner". Basically to write clean code one must write ugly code first. :)
@pipzgutz
@pipzgutz Жыл бұрын
Same thing with enterprise size systems, you start it as monolithic then convert it to microservices down the line.
@BLaBZStation
@BLaBZStation Жыл бұрын
1. Write the code 2. Make it clean 3. Make it performant
@dakoderii4221
@dakoderii4221 Жыл бұрын
Same thing for writing an essay or article. Notes ---> Rough Draft ----> First Draft ---> Second Draft ---> Final Draft
@BGivo
@BGivo Жыл бұрын
Didn't you just describe almost exactly what he said in the video about 'WET'?
@owenlwiantoro6473
@owenlwiantoro6473 Жыл бұрын
@@BGivo I guess the point is it's okay to write the code 'WET' first to get the actual functionality done, then you re-factor and make it 'DRY-er'
@joelwalkley3902
@joelwalkley3902 Жыл бұрын
I love your point about DRY - sometimes the repetition is a coincidence and not an indicator that you are really doing the same thing twice. The separate concerns may deviate later and you don't want to tie them up unnecessarily.
@saman6199
@saman6199 Жыл бұрын
Thanks Brad, just wanted to let you know, you are one of the reason that I have a job as a junior developer today, your material and specially your Udemy courses helped me a lot. Thanks for your hard work and effort and for being a fantastic mentor 😊
@webdevcoursestv
@webdevcoursestv Жыл бұрын
That is high praise and I agree! What were your favorite courses from Brad?
@saman6199
@saman6199 Жыл бұрын
@@webdevcoursestv thanks, 50 JS projects is 50 days, his JS course and in the beginning his html and css course. But the 50 JS projects in 50 days thought me a lot about the JavaScript fundamentals.
@lynguist
@lynguist Жыл бұрын
hey brad, i have been watching your videos for a few years now. first just out of pure interest for the subject ( and your teaching style ), then i decided to try and make a career out of it later on. you helped me a lot on my journey and even after years of content i still find your videos to be extremely beneficial. so, THANK YOU and all the best to you and your family!
@tsydi
@tsydi Жыл бұрын
Every time you helping people to really understand.. so many questions but you always give us all of we need and more... clean, short and awesome.. just my large thanks from one tiny person..
@fabiandev8219
@fabiandev8219 Жыл бұрын
Great topic! As developers we sometimes get into "our ways" and forget that there is a difference between preference ( opinion ) and clean code ( best practice ). The line is thin and we can easily go from one side to another.
@allandiaz4638
@allandiaz4638 Жыл бұрын
I have watched several of your videos and I am French, and it is a pleasure to listen to you because you speak slowly enough for us to understand you well, so thank you :)
@jeffreyo5331
@jeffreyo5331 Жыл бұрын
I agree with just about everything you said in this video. Thank you Brad for the great advice. Your channel has made me a much better developer and appreciate all your hard work.
@Mahila90
@Mahila90 Жыл бұрын
Long time since I've watched your videos but I'm glad to see this channel thriving!!
@dgarvin57
@dgarvin57 Жыл бұрын
I agree completely. About balance and consistency and taking a sane approach. We write stuff that works that is as easy to maintain as possible. I used to be a more hard core DRY coder but I'm now leaning to WET and reducing complexity.
@StephenAinsworth1
@StephenAinsworth1 Жыл бұрын
Naming convention and consistancy is big for me. Someone might not like your style of coding but if they can quickly understand where things belong then it's a massive time saver. That's why frameworks are great because there is normally a standard way to do things
@peetspoon
@peetspoon Жыл бұрын
This is a great great point. Specially when you are trying to make a function that fits multiple purpuses and end up with so many conditionals that you loose track where you are using it and how to actually use it. Yeah I think a good balance between both is key... Thank you Brad that was a great video really made me feel better about not using dry all the time.
@EdLinkIII
@EdLinkIII 11 ай бұрын
Brad, first off I just want to say thanks - you've had a decent impact on the last few years of my coding career (through KZbin and Udemy). Clean code, at least how I "do" it, happens in refactoring. I start off with a decent amount of comments, and what I believe to be good variable and function names... But it's not until I get the project about done and have a better idea of what the code has/will evolve into that I start forming better, more readable code - usually with no comments unless it is to explain WHY I did something, never what I did or how I did it. This is also when I apply DRY and other clean code principles. (My new kick is storing conditional statements in is* variables so my if statements read extremely naturally: if(isValidInput) {...}) My lead dev loves my code, says it's the most readable on the team (including his own).
@PaulBeynon
@PaulBeynon Жыл бұрын
Agree on WET vs DRY. My approach is to get as WET as possible until things are working. Once the behaviour is more or less determined, that's when I spend time DRYING the code up. I think DRYing code before the logic is close to settled just adds time and complexity to figuring out and implementing solutions. But making a working WET solution DRY is relatively trivial with the right mindset and tools.
@GilAguilar
@GilAguilar Жыл бұрын
Thanks for always sharing great insights Brad. I’m currently working on my first major initiative at work migrating legacy code with modern our modern code base. We are all about clean code and where we find out the most about it is when writing tests. Looking at our code coverage always tells us what we can improve on. It’s sure challenging when things are tightly coupled though. That’s the beauty of it we do this because we love it, embrace the challenges and and always look to constantly improve. The search for the “why” is so much fun even when it’s difficult. Cheers ☕️
@user-nn5vq5hl4q
@user-nn5vq5hl4q Жыл бұрын
Helpline📲📥⬆️ Questions can come in⬆️
@carlestutusausmarrugat8889
@carlestutusausmarrugat8889 Жыл бұрын
I personally try to write code thinking "I must understand this code 3 years later".
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@hamid_mahmood210
@hamid_mahmood210 Жыл бұрын
Hello Brad! Sir you are an amazing teacher and your content always help us whenever we got stuck in coding .... God bless you❤ And i agree with everything you have said in this video....
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@JayantBB78
@JayantBB78 Жыл бұрын
Wow. This is why I am your subscriber. Everthing is balanced in wisdom. I am not a developer. Never will be. Learning Programming through videos like yours just for the sake of curiosity and to tweak on some thoughts. Goo job Brad. Love and respect from INDIA. 🥰
@fixTheFish
@fixTheFish Жыл бұрын
I like the sentence "think twice, write once". In my opinion, that's a good way to avoid some mistakes during the coding session. I think that the clean code is something that you will have after a good refactoring when you have the time to check if the initial schema was good and how to make things better. I totally agree about avoiding too much abstraction that leads to future troubles
@royz_1
@royz_1 Жыл бұрын
Couldn't agree more. I have seen tutorials which like to paint things either good or bad. I try not to take them too seriously but having the same mentality from someone like you is good to see.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@jagadeeshkj594
@jagadeeshkj594 Жыл бұрын
Hello, Brad. Thanks for the tutorials and projects at the end, man! Really helpful!
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@esabaliauskas
@esabaliauskas Жыл бұрын
AHA - avoid hasty abstractions (coined by Kent C Dodds).
@odonatojunior
@odonatojunior Жыл бұрын
A-ha - Take on me
@HappyHorge
@HappyHorge Жыл бұрын
I think the best takeaway from this video is to communicate with the people you work with how you want your system to look like, and make sure they understand the road that you are taking when it comes to your code. I usually read a lot and do research before I actually make a system to make sure it will be used by people, which is why I code in the first place 😄Always be open to other ways of solving the problem and learn new things everyday, leave pride and ego at the door 😊
@hamid_mahmood210
@hamid_mahmood210 Жыл бұрын
Yeah that's absolutely true....
@riccarrasquilla379
@riccarrasquilla379 Жыл бұрын
SOLID advice. Keep up the incredible work.
@cyberprompt
@cyberprompt Жыл бұрын
perfect. I understood this as I guess I think the same way. first you get the functionality you want, then look to where you can merge a local method into a more general function with arguments, but not if it starts needing a long if/else or switch. one thing I want to champion is creating an app object that holds as many constant or placeholder variables as possible and comment what everything is used for. It's also great to segment your js into individual files and use gulp to concatenate them later. Really was a help in a very long app I just did to focus on the parts I was working. note: did not use a packer as the client wanted un-obfuscated output and plain css, cuz of course I used scss myself.
@AndyNotSoSmart
@AndyNotSoSmart Жыл бұрын
Thanks for posting this. I have experienced many places in the "clean code" spectrum. Still trying to find my sweet spot. Also, I am the "screw it, it works" one. But I am aware of it and I am learning to plan on spending more time reviewing, revising, and addressing outside comments and feedback. For me it boils down to 2 things: 1. I love my quick easy solutions and it's tough to let them go, 2. I am probably in too much of a hurry too much of the time.
@fizzdevdesigns5699
@fizzdevdesigns5699 Жыл бұрын
Another very interesting content 👌 Thank you so much for putting it out there! I like the idea to find a balance guided by sound analysis of the project's need. And, yes, readability is key to better communication, so it is hardly ever to bad choice road. Thanks again!
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@yusufusman2920
@yusufusman2920 Жыл бұрын
Hey, Morning... I was just wondering if your discord group is still active, cuz the one I got couldn't get me into the group.
@webdevcoursestv
@webdevcoursestv Жыл бұрын
I ALWAYS love the down to earth, grounded takes Brad gives us. Writing clean code takes so many years, you can't stop writing code just because it isn't "clean". First you have to write the "icky" stuff to get to the "good" stuff. I agree with Anson. Less gatekeeping! Instead of telling people their code isn't clean, we can just offer patterns and tools. Coders tend to be much more binary than other people.......
@Deanin
@Deanin Жыл бұрын
Completely agree. It's definitely a spectrum that some people tend to apply absolutes to. It does get a bit frustrating seeing the comments sometimes from people who might mean well, but are really just generalizing their preferences in a not so polite way lol. Looking at you, parts of the Rails community 😂
@areamobile4629
@areamobile4629 Жыл бұрын
Thanks Brad
@MatrixCL
@MatrixCL Жыл бұрын
Good point, and I definitely agree with the middle ground between WET and DRY. Keeping your code clean of any comments is dangerous, though. What might seem self-evident right now, might have become obscure when you look at it again one year later. Consistency in style definitely increases readability and I strongly encourage that especially in team work, otherwise it can become a real mess. In our project, Prettier enforces this, meaning every time I press ctrl-S in VS Code, all the double white spaces, too long lines, missing semicolons at the end - we prefer those - are fixed instantly. Now our code looks as beautiful as Anne Hathaway.
@user-qp6se2tn4r
@user-qp6se2tn4r Жыл бұрын
Whats up with my prettier it doesn't work l even Uninstalled and installed vs code 2 times?
@MatrixCL
@MatrixCL Жыл бұрын
Probably you need to fix the settings. But I'm no troubleshooter, and KZbin is not exactly the best place to find help anyway.
@Flopshoubox
@Flopshoubox Жыл бұрын
This is great to see some nuance on this subject !
@user-nn5vq5hl4q
@user-nn5vq5hl4q Жыл бұрын
Helpline📲📥⬆️ Questions can come in⬆️
@ev721
@ev721 Жыл бұрын
Finding that middle ground as so far worked best for me.
@marcodupas8960
@marcodupas8960 Жыл бұрын
Nice ! I'm just starting to understand this after a few years coding.
@chewhx
@chewhx Жыл бұрын
You’re right. Mostly it’s down to preferences. I tend to disagree with most settings we have in company repos, but hey it works for everyone so, that’s what it means to work as a team.
@adamjamiu6764
@adamjamiu6764 Жыл бұрын
Brad! You are my genius 🙂
@BoolFalse
@BoolFalse Жыл бұрын
Thanks Brad !!!
@BetYouHateMeNow
@BetYouHateMeNow Жыл бұрын
I have to agree with you as a person just learning about a month now. I have heard both sides and have watch people try to interject their way as the golden standard. To me all that matters is the syntax and practices of the language. Noobs like myself don''t need people confusing them.
@ricardocnn
@ricardocnn Жыл бұрын
Thank you man!
@hserittg
@hserittg Жыл бұрын
I think I unknowingly learned the W.E.T. approach through sysadmin work without knowing its name. I initially made the mistake of automating without fully understanding the process and its requirements, leading to continuous difficulties until I eventually got it write. Sometimes this could take months. Ugh. To avoid this, I now repeat a process manually several times to understand it before automating, using a simple scripting language first, then refining and possibly using a more sophisticated tool. This helps me ensure I understand the process before automating and reduces the need for frequent bug fixing.
@pjf7044
@pjf7044 Жыл бұрын
Interesting video. In my less experienced opinion, especially in JS that there are tons of different ways to write input that produces the same output, there is no way to correctly write code. However one thing I do believe in is writing dry code and avoiding redundancy. My day job is mechanical engineering and I need to produce blueprints, and I practice the same concept within my drawings. I don’t repeat myself or present the same information twice, and try to simplify things as much as possible. Like math,Anyone can complicate and add things but it takes intelligence to simplify them, while still retaining the same critical information.
@serpian220
@serpian220 Жыл бұрын
When I saw the title of the video I thought for a moment that you were going to talk about the book by Robert C. Martin. Well, as for myself, being a PHP programmer, I try to follow the PHP Standard Recomendations PSR-1 and PSR-12.
@jeromebacatan8081
@jeromebacatan8081 Жыл бұрын
Thank you.
@user-tq8kp6pt9w
@user-tq8kp6pt9w 7 ай бұрын
Thanks! 💯
@hugot8226
@hugot8226 Жыл бұрын
Hey Brad ! Thank you a lot to reassure us that the "grey zone" is always what we should target.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@MrVoidfull
@MrVoidfull Жыл бұрын
You are pretty much on spot here. "Clean Code" stands mainly for readability and maintainability. When you work in a project with 200 other developers spread across the globe, the term 'clean code' means readability just as much as it means performance. That means that if you can write either one obscure and obfuscated one line, or 4 lines which are understandable a glance, you always write the four lines, even if the one liner is 3% quicker or more efficient or what ever. Execution time for a program is of course important, but you don't need everything to have perfect speed, especially when that part of the software might be run by users once every two days. But having a developer sped 2 minutes and a stack overflow search just to understand what that one liner is supposed to do is not good.
@nathansnow
@nathansnow Жыл бұрын
Hit it all on the head imo 👌 Like you, I don't feel commenting needs to be one way or the other. Make your code as self-explanatory as possible, and add documentation (e.g. javadoc), but if you feel something still needs more info or examples, just add it. To help with abstraction, I like to go by a TDD approach because it helps me write both clean, and the minimal amount of code to get the job done. Like you said though, if you're in a situation where your code has to follow some guidelines, then the guidelines are your Bible
@tobiasfuchs2502
@tobiasfuchs2502 Жыл бұрын
There is no way that you posted this video just when I was reseraching about the topic. Also, I saw your "imposter syndrome"-video recently - you are awesome :)
@user-nn5vq5hl4q
@user-nn5vq5hl4q Жыл бұрын
Helpline📲📥⬆️ Questions can come in⬆️
@FunnyTechBro_
@FunnyTechBro_ Жыл бұрын
Thanks boss
@aes0p895
@aes0p895 Жыл бұрын
the biggest problem with "clean code" that i've had is instructors who insist on refactoring everything in the most abridged "simplified" version possible so that it's impossible to tell what anything does just by looking (at least at the skill level the course was intended for). This leads to students just following along, barely able to keep up or understand what is happening.
@user-ur4ev7vl6c
@user-ur4ev7vl6c Жыл бұрын
It's Senior Developer's fantasy :)
@lovehalfblack9420
@lovehalfblack9420 Жыл бұрын
Dope north face sweater 🔥
@ahmad-murery
@ahmad-murery Жыл бұрын
Staying in the middle is the safest option at least to me, I listen to both DRY and WET opinions, get what is best for me and forget about the trend because they keep changing, Thanks Brad 👍
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@natepepin09
@natepepin09 Жыл бұрын
I think having a design philosophy helps and can increase readability, though that is partly just with being familiar with how the architecture works. I think different philosophies have strengths and weaknesses and which one to choose is mostly preference, but I also think that a lot of people write bad code that would be improved greatly from a philosophy. I think the issue is that most of the criticism people make is against people who write pretty good code, and those people don't understand why they are being criticized. Why this is, who knows, but it's common with other fields too, there tends to be more back and forth between groups that are more similar than groups that are further apart.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@logiconabstractions6596
@logiconabstractions6596 Жыл бұрын
Not being intimidated/thinking you're writing bad code because someone else promotes a different idea that isn't better, but just different, is indeed important. I would add that conversely, before we start arguing all that strongly about such and such practice, we should also ask ourselves whether we're just starting an argument about trading 4 quarters for a dollar. I think it does run both ways, and if all programmers were able to exercise that self-restrain sometimes, we'd all be better off!
@girornsveinsson7970
@girornsveinsson7970 Жыл бұрын
Completely agree with everything you said! :)
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@g0unsch
@g0unsch Жыл бұрын
Clean mode is the code that follows SOLID principles. Period. The principles were written decades ago and are still relevant.
@naveenbelandur7269
@naveenbelandur7269 Жыл бұрын
Nice topic guru
@markmahowald7866
@markmahowald7866 Жыл бұрын
Well seeing as I’ve never had a code review at my company… I follow the looks good to me principal
@spldigest
@spldigest Жыл бұрын
Hi Brad! can you please have a crash course on how to document a laravel project using sphinx, a python based application project document generator. Thanks!
@tonytenorio8482
@tonytenorio8482 Жыл бұрын
Awesome video
@aniketsingh6381
@aniketsingh6381 Жыл бұрын
Some devs say do not use too much divs while some say use divs appropriately, but in my way I prefer the use divs as a when required because of the complex designs, we cannot just rely on a single div doing all the things at the same time. This is also a concern in Good practises vs preferences.
@CoderDmitri
@CoderDmitri Жыл бұрын
100% on board with everything Traver says... I actually quit one of my roles as a developer, because the dude kept forcing his style on others for no reason what so ever, AND the worst thing of all is that his style was very very time consuming and just bad, many things he was doing had no logical reason to be done, yet he just likes to do it, so we have to do the same... lol!
@brianmmdev
@brianmmdev Жыл бұрын
I really think it all comes down to moderation. I've always assumed that when devs talk about "Clean Code" they are referring to the classic by Robert Martin. While I agree with many if the ideas he puts in the book, I think its important to recognize that they are guidelines more than anything. For instance, I generally try to write descriptive code to avoid comments, but sometimes it just makes more sense to leave a small comment. That said, I've never followed the 'newspaper function ordering' recommended by the book. It feels like a lot of work for very little return. Also, I literally lol'd at "best practice fascists 😂". Great video!
@cassolmedia
@cassolmedia Жыл бұрын
as a recovering "screw it, it works" programmer, I fully agree :-) ...I definitely end up somewhere in the middle these days. Never been a fan of "clean code" or DRY, as it usually just feels like complexity for complexity's sake. I prefer to write code that works, and then refactor as necessary to get to production-ready.
@samiullahsheikh5015
@samiullahsheikh5015 Жыл бұрын
WET principle totally make sense to me. Until I write some code I cannot figure out which part needs to be put in a separate function. Keeping too much focus on DRY or good/efficient code at very first iteration make me write no code at all. I write some code and then revisit the approach and see what can be extracted out in a function. Even I rewrite those extracted functions when I see they are needed more like a utility. It's like writing an essay which become good enough after rewriting the first draft again.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@ore_bear8045
@ore_bear8045 Жыл бұрын
In my opinion its rare to see much comments. Code is much more maintainable if you write it readable with a lot of comments and even use comments as a way to section the code typography. But many programmers like to write code that look as complex as possible.
@abdullahsoomro6238
@abdullahsoomro6238 Жыл бұрын
Love it❤.
@kouzul
@kouzul Жыл бұрын
I agree on what you said, except DRY vs WET. I find it much easier to maintain the code when its DRY. If there are too many cases to handle, then split the function in multiple functions, each with its scope. Clean code should make the code easier to read, thats all I think about when I write code, and I'm doing it for me... usually its me that I need to debug the code months after I wrote it.
@knabbagluon
@knabbagluon Жыл бұрын
And I don't think a dry code is spaghetti code. If your functions and methods "speak" it is easy to read. Because I don't even need to view the function. The name tells me what it does. And when I see the function again, I'm already familiar with it.
@Bibi_effin_Blocksberg
@Bibi_effin_Blocksberg Жыл бұрын
The latter part, where you say "I write code for myself" is dangerous. At least in professional environments it's quite the opposite (even when you're the only person on the team writing code at the moment). By the end of the day other Devs will have to work with your code - and that's the target audience of your code. I always say "would a Junior Dev be able to work with my code without having a mental breakdown?" as a rule of thumb when it comes to quality. Because if not my code might be too complicated, obfuscated ans without clear intent.
@kouzul
@kouzul Жыл бұрын
@@Bibi_effin_Blocksberg You didn't quite get my ideea. I write the code for myself in the way I will need to understand it like it was written by someone else... KISS you 😁
@Bibi_effin_Blocksberg
@Bibi_effin_Blocksberg Жыл бұрын
@@kouzul ahhh alright then. KISS is the best.
@charbelsarkis3567
@charbelsarkis3567 Жыл бұрын
Used agora in a job once. The documentation wasn't all that clear. Didn't pass probation because of it. Albeit the company I worked for didn't even get the premium tier.
@Hacking-NASSA-with-HTML
@Hacking-NASSA-with-HTML Жыл бұрын
Hi there! Just an opinion, Agora didn't work for me 🤷🙁 There was a tutorial on this channel, not by Brad, some other guy, Dennis? (not sure) about video chat using Agora software. And it doesn't work. And Agora tech support just put me into useless communication like "send us errors in your console, but a couple of hours ago I sent them a screenshots with those errors 🤷🙁
@Hacking-NASSA-with-HTML
@Hacking-NASSA-with-HTML Жыл бұрын
And now it sits on heroku, and does nothing correctly 🤷
@Hacking-NASSA-with-HTML
@Hacking-NASSA-with-HTML Жыл бұрын
And everything ended up in "Use our ready app templates" 🤷🤦‍♂️
@terraflops
@terraflops Жыл бұрын
"clean code" to me means code that is spaced apart (readable), variable names are informative and some comments of what some/ parts/ sections of your code does/ is. Comments are gifts for future you (and others), The WET approach is also nice but i often want things to be in functions/ classes to maximize laziness.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@i_o_media
@i_o_media Жыл бұрын
hey brad i have been trying to reach you but all effort seem futile, it will be really love it if you make a web 3.0 crash course 😊
@paulexconde5189
@paulexconde5189 Жыл бұрын
From personal experience, writing clean code cannot achieve without writing messy code, it is a gradual process of writing better code, programming languages, framework and other tools helps us not to force to write clean code, but to organize our minds as software developer.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@your_utube
@your_utube Жыл бұрын
Clean code could mean Maintainability. Maintainability is often dependent upon where it applies. This can mean the old rule of "more comment than code" would work in many situations, even though it may annoy some people. Some oft-ignored and well-established principles like "structured programming" tends to help avoid logical holes in algorithms. To have a formal algorithm for something or a specification document may also be what leads to clean code. Presumably it is easier to read through a spec and/or algorithm before trying to decrypt code based on it. The maxim here is that "what cannot be designed cannot be built." Clean code could also refer to object-based or object-oriented code. The logic here is that perhaps knowing the actors in the model upon which the coding is based can be read and understood far better if they can be related to something in something like a UML spec. Following the UML or ERD or some other diagram during coding could be construed as clean code. In that sense, "dirty code" would perhaps entail doing coding for which there is no relatable representaion in these formal document specifications and diagrams. When I was still active in the ICT industry, I often found that it really helps to produce some form of spec or another and perhaps even diagrams, if the task is huge or complicated, or there is the possibility that it could grow large (which it inevitably does) and where you may need to try and figure out what you did a while back or try and explain it to someone else. Code cannot be clean if neither you nor your successor/maintainer can later follow it, but even simple documentation is better than none, even if all it contains are some explanations as to what you were trying to create and how you planned to proceed, expected pitfalls to watch out for and avoid etc. Guarding against analysis-paralysis is also so important. Finally, I really think that clean code instills a sense of confidence, irrespective of what you define as clean code. Sorry for the long speech...
@rottencorp666
@rottencorp666 Жыл бұрын
As one who has written stuff -- not just code, but documentation, systems backgrounds, website articles, books, manuals since 1965; some systems I have written had run for 20 years, on many different hardware / software platforms -- let me offer something everyone might find useful: Never underestimate your ability to forget stuff. As unlikely as it may seem, with how quickly everything changes, it may be less likely that you will have to revisit something you've written 12 years ago, but you may always want to tuck that away if it should ever come up again. Occasionally, I will use a tool in my chest I haven't touched for 15 years. I don't think you can ever know. To that end, if you want to be safe and effective, make sure that you have useful documentation one way or another that will help you way way down the line if you ever have to come back to something. You can even write really clever stuff, but make sure that as memory and ability fades, you will have an effective working knowledge as mitigation for challenges in the future, besides being able to reuse you need at a later date. One other observation: Best practices are useful, but just remember that absolute project management caveat: If you do the same things under the same circumstances, you''ll get the same results. Consider this: If that is absolutely true, explain, if you can, the binomial theorem and the Galton Board. A word to the wise should be sufficient.
@chivicks_hazard
@chivicks_hazard 10 ай бұрын
Well I think the best thing to do is to maintain your coding signature because it's who but make sure that someone understands 30-50 percent of it and it works
@Cubesan1202
@Cubesan1202 Жыл бұрын
You look like Fred Durst from Limp Bizkit. Best regards from Poland.
@TheCodeCreative
@TheCodeCreative 6 ай бұрын
Avoid Hasty Abstractions!
@cruzchaps3662
@cruzchaps3662 Жыл бұрын
As a self taught student i realise that dry is too complicated since you wont know what shouldnt be repeated. Especially when it to queries to the db
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@bhagyalakshmi1053
@bhagyalakshmi1053 Жыл бұрын
Hi What my classes jod recharge time.
@josheonate8278
@josheonate8278 Жыл бұрын
Clean code is just a term, there isn't any specific definition to it. It's just a good way to structure your code so is easier to understand and follows most of the standards that the majority of the community defines as the best way to do it. It's definitely changing by the time with standards like DRY, SOLID etc.
@anakngjiho2702
@anakngjiho2702 Жыл бұрын
Wow. I’m not the only one who thinks that write everything twice makes sense.
@RD-jr8nv
@RD-jr8nv Жыл бұрын
When there is no Style Guide for how code should be written. I pretty much just go by Air BnB, it's logical and makes my code consistent.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@BoolFalse
@BoolFalse Жыл бұрын
it's important to hear your thoughts as well..
@danielcrone9553
@danielcrone9553 Жыл бұрын
When did Fred Durst learn to code?
@tkdevlop
@tkdevlop Жыл бұрын
get sht done & move on is the best code
@catharsis222
@catharsis222 Жыл бұрын
Clean code is having comments. Settled! 😉
@pipzgutz
@pipzgutz Жыл бұрын
Your code should be readable enough so that when you go back to your code after several months you’ll be like “wow, I made this code!?” not like “wow, I made this code.”
@CryptoRoast_0
@CryptoRoast_0 Жыл бұрын
Messy code is job security 😅👌 if no one else understands it they can't get rid of you 😅
@Thorax232
@Thorax232 Жыл бұрын
The problem is your average developer takes "subjectivity" and uses it as an excuse to push problems off until later (which is another way of saying never), or to never improve. You should strive for writing code that nobody questions. If you have to constantly reassure yourself that what you're doing is just "your style" you might be the common denominator.
@adamjamiu6764
@adamjamiu6764 Жыл бұрын
This is exactly me
@ar4be
@ar4be Жыл бұрын
I think “clean code” is nice as you said while you are not repeating yourself over and over again. Some guru coders often overkilling it so your code may be a bit faster but it’s getting hard to understand , so that level of “clean code” is too much. That’s my opinion.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@syntaxed4365
@syntaxed4365 Жыл бұрын
I do think the term "clean code" is largely subjective. For me it means ease of readability, for most people. I personally don't mind seeing a couple of 'if' statements in a row, if it's easier to read and manage, versus a crazy one-liner with chained ternary operators and regex. Yeah, the latter example is cool to do, and feels efficient, but if it stops the next person in their tracks, then it's not that useful IMO.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️.
@msrumon
@msrumon Жыл бұрын
Clean code, to me, means following language-specific guidelines. So as long as you don't write `some_variable = 'bla bla'` in JS and `someVariable = 'bla bla' in Python, you're good to go. Also, now I think I should also give +1 to naming variables and functions meaningfully and overall code readability to humans.
@user-vk8kt3tp1g
@user-vk8kt3tp1g Жыл бұрын
Questions can come in⬆️
@MadiMisaki
@MadiMisaki Жыл бұрын
I write comments in my mothertongue.
@JohnDoe-bu3qp
@JohnDoe-bu3qp Жыл бұрын
I think developers should look at their code with a SOLID mindset, just as they should look at it with a performance mindset. Now, that doesn't mean your do all the refactors that are possible, just that you should learn to recognize them for when they make sense. The term "clean code" seems a little heavy to me, as someone else already mentioned.
@emekatimothyiloba699
@emekatimothyiloba699 Жыл бұрын
I’m just hearing of the wet principle for the first time
@FloodGold
@FloodGold Жыл бұрын
Get it working, optimize it, next.
6 Of My Personal Tips When Learning To Code
7:46
Traversy Media
Рет қаралды 168 М.
Stop Recommending Clean Code
27:05
ThePrimeTime
Рет қаралды 391 М.
Melhor Gadget para Dias Frios! 🔥
00:31
Poly Holy Yow Portuguese
Рет қаралды 10 МЛН
Will he fulfill the child's dream?💔
00:54
Filaretiki
Рет қаралды 43 МЛН
5 Pro-Level React Do's & Don'ts
30:06
Traversy Media
Рет қаралды 171 М.
This is the Only Right Way to Write React clean-code - SOLID
18:23
5 Design Patterns Every Engineer Should Know
11:51
Traversy Media
Рет қаралды 927 М.
Dealing With Some Common Frustrations As A Developer
11:31
Traversy Media
Рет қаралды 73 М.
Junior Vs Senior Code - How To Write Better Code
22:13
Web Dev Simplified
Рет қаралды 1,1 МЛН
Why You Shouldn't Nest Your Code
8:30
CodeAesthetic
Рет қаралды 2,4 МЛН
ChatGPT Crash Course | 10 Practical Use Cases For Developers
32:34
Traversy Media
Рет қаралды 160 М.
Clean Code is SLOW But REQUIRED? | Prime Reacts
28:22
ThePrimeTime
Рет қаралды 220 М.
Stop Worrying About AI!
6:40
Traversy Media
Рет қаралды 44 М.
Are You Too Dumb To Code? A Chat About Imposter Syndrome
7:08
Traversy Media
Рет қаралды 58 М.
Technicians are testing this LED module. #leddisplay #ledwall #ledmodule #ledscreen #eagerled
0:18
Apple Vision Pro
0:42
Янчик
Рет қаралды 11 МЛН
Взял Samsung Z Fold 5...А стоит ли? нужен он?
16:43
РасПаковка ДваПаковка
Рет қаралды 53 М.