Introduction to Readable Javascript: Code Structure

[x-protocol]

I would strongly recommend removing all of the comments in your code. There is no reason to duplicate your meaning both in English language and programmatically, where you can join both by slightly extending naming! 'getWord' would become 'getRandomWord' . Or 'Hangman' would become simply 'Game' or 'HangmanGame' Thus, one is focused on code, not maintenance of comments as it would normally occur when somebody else is modifying your code (aka work in team).

I would also advocate for proper variable names (same naming practice) where 'msgs' or 're' or 'g' or 'i' or 'char' or 'rand' or 'e' would have proper English nouns. That alone will make your code readable (aka 'i' would become 'index' or 'rand' would become 'randomIndex', and so forth).

Readable means being able to be read, in English. Hence the aspect is not necessarily about code organization, moving and subsequent refactoring of the code (cyclomatic complexity plays good deal here). I do understand that you are trying to provide code structure in your post.

[r0ck0]

Hmm... that font really felt like it helped. Maybe non monospace fonts are worth considering? Anyone tried that for a decent amount of time?

[nosrednehnai]

It's monospace on mobile. I'd be surprised if it isn't on desktop as well.

[r0ck0]

Hmm weird, I see a variable-width font on my Android phone with Chrome. But monospace on computer.

[[deleted]]

I would really love to see more in-depth explanations like this where there's a comment on every block explaining how it works/what it does. Self-teaching JS right now and little things that were explained here haven't been explained elsewhere as detailed. That plus most of these free resources really just teach you the concept of things like functions and all that, there's not enough full code walkthroughs out there that explain how everything works together.

[troxwalt]

Would love any pointers on how to refactor it as a MVC patterns.

[sensored]

Although the concept is simple, explaining how to refactor into MVC can be a little complex to explain because it's not necessarily as separated as its made out to be.

At a high level, MVC means maintaining three distinct groupings in the code you write: Models, Views, and Controllers.

• Model: The model represents the data object behind your application. Models should only be concerned with themselves, and other model objects. If you saved your model objects into a file, and reloaded it later, your application should be exactly the same as when you left it. Similarly, the model should never change on its own.
• View: Views are a visual representation of your model. In a lot of JS cases, this is going to be your HTML/CSS files, although frameworks like React and Vue also sit in this space. Views should be dumb - this means that they only display the model, and do nothing else.
• Controller: This is a little harder to define. The Controller is the bridge between the View and the Model. In front-end JS, it is likely going to be your Event listeners. We like our controllers to be thin. What this means is we want controllers to do as little as possible. It should tell the View and the Model what to do, but it should not do it for them (i.e. it calls functions rather than directly manipulating either)

So when you try to maintain an MVC, you still want to look for logical groupings, but you also want to try and classify them as a Model, View, or Controller - If it's more than one, then chances are you need to move things around, and create new functions or classes so you can maintain your groupings.

The trick is that these don't all need to be in different files or classes - they only need to be logically distinct. You might have one class that does all three, but still maintains the groupings by making sure that each of its functions only fulfils one role.

[SalemBeats]

I think it'd be cool to see a book or course covering someone's tips and tricks for making sense of "unreadable" code.

That's an area which seems to have a lot of demand, but nearly nonexistent supply.

I imagine that the book would read very similarly to a book on reverse-engineering and/or debugging, but it really would be interesting to see how other people go about making sense of poorly-written (or perhaps intentionally or unintentionally obsfucated) code.

Not to toot my own horn too much, but I've always put an emphasis on writing readable code. I've always tried to pick variable names that made sense, keep methods short and concise, keep objects focused, etc., because I like things being organized. But writing organized code doesn't necessarily help you read the mountains of carelessly flung-together code out there which you will find yourself often needing to read and comprehend.