Bad Code v.s. Good Code

[@RodnDjokYTB]

very helpful! keep up with these kind of videos.

[@ConnerArdman]

Thanks! Glad you found it helpful! 😃

[@juanferrer5885]

Great video Conner!

[@FilhoLouco]

I agree with the video. A friend of mine said that applying SOLID will make my code always, the problem is that I didn't quite understand all the solid yet. Do you if it apply for a language like javascript?

[@ConnerArdman]

Design principles are all just general guidelines, most can't always be 100% followed. In the case of SOLID, I think they are generally good principles for most object-oriented programming. That said, when you are writing more functional code like most modern JavaScript tends to be, a lot of SOLID isn't particularly applicable. My general rule is to focus on the 5 criteria of good code I gave in this video - correctness, readability, maintainability, testability, and performance. Principles including SOLID and the ones I mentioned in this video are just rules of thumb that can usually lead you towards fulfilling that criteria. However, you should still put the criteria first, and think critically about each use case rather than following any of the principles blindly. So am I actively intentionally applying SOLID while writing JavaScript? No. However, when I do write more object-oriented code, it usually ends up following those principles anyways.

[@reda29100]

4:00 but you can simply call the common part together, and then process each branch later, can't you? fun_1() do_common() do_unique_1() // or extensive code not in an inner function fun_2() do_common() do_unique_2() Of course, you may need to get variables back which could be resource-expensive (like game frame when time is of utmost importance)/cause an issue with non-pointer languages, which otherwise would process info and may return smaller values. Can't you?

[@ConnerArdman]

You can, and this definitely isn't a terrible idea. I think it would just depend on what exactly that common code is, its likelihood to stay common, and how closely it relates to the unique code. In this case, the common and unique code would both be criteria for a successful signup. In my opinion, having that partially in a shared function and partially in separate unique functions would be on the edge of violating the DRY Principle as now there are 2 separate places to look for the criteria of a user signup and 2 places to look for the criteria of an admin signup. The alternative would be just 1 place to look for each (but of course 2 places if someone did need to change both, so there is an argument to be made based on how closely related admin and user accounts are in the hypothetical scenario). Additionally, if you went the common function route, then if anything else changed down the line you would have to be extra careful to edit the right functions. For example, if the name requirement was removed for users, a developer might just remove it from that helper function. But then they would have to know they need to now go into the admin unique function to add the name requirement back for admins. Of course you would hope this would get caught by tests or mentioned in documentation, but keeping the code separate avoids the concern all together.

[@reda29100]

​@@ConnerArdman Mentioned case can be treated like: def admin_fun(): validate_credentials(admin_info, admin_name_min_len = 6, admin_pass_min_len = 12, admin_min_age = 18) # Last argument might be rediculous for saying a user must be at least 13 by admin must be # at least 18 but you get the point of customizing arguments do_unique_1() def user_fun(): validate_credentials(user_info, user_name_min_len = 6, user_pass_min_len = 12, user_min_age = 13) do_unique_2() def validate_credentials(account_info, acc_name_min_len, acc_pass_min_len, acc_min_age): if len(account_info.get_name()) < acc_name_min_len: raise Exception('Account name must be at least %d in length'.format(acc_name_min_len)) # can customize "Account" if you will # Can as well customize it to "must be at least %d (was found %d)" if len(account_info.get_pass()) < acc_pass_min_len: raise Exception('Account password must be at least %d in length'.format(acc_pass_min_len)) if len(account_info.get_age()) < acc_min_age: raise Exception('Account user\'s age must be at least %d years old'.format(acc_min_age)) ... My point being, if I can customize the function (readability wasn't compromised I believe), I'd do so personally. However, for general case where simple different arguments won't cut it (entire lines are different for each case): def common_fun(args): ... # This would become messy, and I'd have to name common_fun an appropriate name for the incomplete processing # Of course, won't be there; just for illustrating the point

[@forthehomies7043]

Very helpful man

[@psygnozis]

and thast...O K A Y Y Y YYY

[@tkdevlop]

no offence but my code quality depends on my hourly/project rate as a contractor.

[@ConnerArdman]

Yeah another case I didn't mention in the video is that micro-optimizations and super clean code just doesn't matter as much in small codebases without a desire to scale. Most companies hiring independent contractors fall in this category, so I don't think this matters too much. For example, if you are contracted to make a website for a local business, writing modular code really just doesn't matter. Features are the product, not the code. You're giving them a better service by charging them less money for "worse" code that takes less time to get to the same features.