The Art of Clean Code: A Practical Guide to Writing Maintainable JavaScript.
Introduction:
Writing clean code is more than an...
For further actions, you may consider blocking this person and/or reporting abuse
This is of course something you should never do... Function wrappers are evil. Just call
Math.random()directly.Maybe what you mean to say is something along the lines of: "use some form of dependency injection to improve testability."
This was an example of creating something that is testable. In this case, he's using Math.random since it's a great example of non-deterministic code which is horrible for unit testing. You don't want unit tests that fail sometimes and pass others, nor do you want meaningless ones. I think it might have been more obvious if the function was doing more than simply wrapping Math.random, but beyond that, it was an excellent example of doing di well (although, I'd personally have probably put it into a special object literal that I'd have called di or something that would make it clear and obvious that this is what it's for).
It probably would have been even better to show an example with an import, as this is a great way to handle di with imports. The default is the import, but it can easily be overriden with the injection.
The only thing that might be even better would be to create a closure around it so you don't need to continuously reassign the value. Or, if you must use classes (not my recommendation in JS, actually), then use a singleton or similarly scoped class.
Ok Very good - I was really struggling why he had chosen such a for lack of better language random function to simply be returned. Difficulty again I may be missing something that should IMO never be called good. Maybe a clearer explanation in the op. Logical but if you know its not an issue. Great work though
Look at my response to @brense, in that I suggest doing something in the function that handles a specific scenario that might occur with the random function.
If you have that, it would better reflect the reason for di (which I usually prefer over import mocking).
The core purpose of Dependency Injection (DI) is to handle specific scenarios that might occur with random function generation. For instance, if a random number falls outside a desired range, you could re-generate it or handle exceptions. Such logic would demonstrate a more meaningful use of DI.
If you need Math.random to return a specific number for one of your test cases, you just do:
Math.random = vi.fn(() => 0.1)Dependency injection can be useful and can simplify testing in certain cases, but this is not one of them.
Hello ! Don't hesitate to put colors on your
codeblocklike this example for have to have a better understanding of your code 😎wow great, thank you so much.
These are all really great examples ( obviously #3 as an example of dependency injection rather than an actual way to generate a number) of clean code that is not slow code. But keep in mind the term clean code often is synonymous with slow code. Don't abstract just for the sake of it.
Great article!,
I love the focus on readability it is by far once of the most underrated issues today as javascript is so flexible you can do anything in n^2 ways.
I also love that you did give room for the question of readability vs performance, most article choose one or the other.
The best thing I can say for this article is that I think it should be a basis for code review processes.
so shkran.
For #4, i'd argue a switch is even better than both other options. The first example with a ton of if statements is clunky and the exact reason the switch exists. The second example needlessly splits up code that makes it less readable and doesn't catch errors like the case not existing.
Everything looks great! I follow clean coding/coder principles as well. Great job 🤜!!
However...
No 3. Testability example? Um.. uh... No easy way to say this 😵💫: Nope. I was reading in a mobile, the code was cut off, and I thought you were sending in a seed for predictability, but sending in a function that replaces the only job of the system under test? Nope. Can you give a better example, please? Like, Math.random() takes a seed, send that as argument from test file.
I understand this is only a 3 line example, but IMHO, the example, to the untrained mind, can present a whole list opportunities to get it wrong.
Testing is not hard, but people can make it hard. A weak test is no better than no test. Any code is testable. You wrote the code, you have the scenario in mind, set that scenario up and see how your code behaves. Repeat for each scenario. Finally, automate on each commit.
What I would suggest for a testability example is what you have in the explanation for No 3: Break it down. Modularize for testability. Cleaner dependency injection for predictability, like stubbing Math.random through external means and run the system under test.
Better yet, TDD. If you can't test it, you don't have to write code for it. That's how you get inherently test-
able-ed clean code.Happy coding ✨!
tnx.
This is one of the best articles on clean coding I've seen for JavaScript in a long time. There's a couple areas that could probably be described in a bit more detail so that the intent isn't so easily misinterpreted, but overall this is really good.
I've been writing JavaScript since the year it came out. Over the years I've discovered things that work and things that don't. The things you have here are in the group of things that work (when applied properly).
You even included one that always seems to throw people off (the one under scalability where you are using an object literal in place of a switch or multiple if/else blocks). I love that one. Once people understand it, it's very elegant and, in my experience, frequently faster than the alternatives.
I think there are even more things that can really improve the JS experience, but so far, this hits most of the major things. Kudos.
For configuration, my best TypeScript work so far (v3 in beta): wj-config
It excels in large and complex projects, but can also be used easily in simpler ones. The best part is that it works identically in NodeJS projects as well as browser projects, so it covers all of your JavaScript needs.
This sounds like an excellent resource for anyone looking to improve their coding skills in JavaScript! Writing clean, maintainable code is crucial for long-term project success. Some key principles that might be covered include:
Readable Code: Use clear variable names, consistent formatting, and proper indentation.
Modular Design: Break code into smaller, reusable functions or modules.
10.0.0.0.1 – 10.0.0.1
Avoiding Complexity: Write simple logic and avoid deeply nested structures.
Documentation: Add comments where necessary to clarify intent.
Searching for an online streaming application to watch your favorite entertainment shows and movies with free downloads? Your search ends here! Cinema HD apk is one of the most excellent online Streaming applications, having a good quality output and a very large database of movies.
Cinema Hd is super-efficient and it is extremely well-known regarding results. It’s also available on PC, IOS, Mac, and other devices out there. There are many apps related to this, but it’s pretty much the best because of the features.
thank you.
just wow ♥️.
tnx.
"The Art of Clean Code: A Practical Guide to Writing Maintainable JavaScript" is a guide focused on writing clear, efficient, and maintainable JavaScript code. It emphasizes best practices, code readability, and organization to help developers improve the quality of their code and avoid common pitfalls.
castleapp
"The Art of Clean Code" is a practical guide that teaches writing maintainable JavaScript by focusing on readability, modularity, and best practices. It emphasizes clear naming, proper documentation, and optimizing code for collaboration and scalability.
Thanks for sharing :) great work
welcome...
we need a python version
Great Article bro, Enjoyed reading, hope to see more from you!
Thank you, brother! I really appreciate your feedback. I'll try to bring even better content in the future, Insha'Allah! 😊
I think at point 2. The provided solution will still need a if-else chain especially when we need to attend to those specific errors from those asynchronous functions in the try clause
I agree with you. tnx
I logged into dev.to just to give thumbs up on your expressivnes. Like!
wow. thank you so much brother.
Wow! Thank you!
welcome.
The good code for Scalability,4, seems wrong
Thank you, I checked again, everything seems to be correct.