7

Web Tools #445 - Chaotic JS, SVG, Git/CLI, React

 2 years ago
source link: https://mailchi.mp/webtoolsweekly/web-tools-445
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Chaotic JS, SVG, Git/CLI, React

Issue #445 • January 27, 2022

Advertisement
Free Talk with a Data Expert Data is important to your business, but learning about the right tools and best practices is more difficult. Our data experts are here to help. Schedule a Consultation

A recent article called Chaotic JavaScript Patterns got me thinking about the way I tend to write code nowadays.

I write a lot of tutorials, blog posts, and newsletter intros that feature various front-end features and techniques. A lot of my day-to-day work involves creating small demos and reduced test cases to show off these specific techniques.

One thing I find myself doing a lot in these encapsulated instances is writing the worst code imaginable just to get things working. Once I have the working demo in place, I go back to refactor the code to ensure it's more maintainable.

Some of the refactorings I commonly do are:

  • Store DOM references in variables, rather than repeating each reference for every use
  • Convert old-school string concatenation to template literals
  • Move common tasks across functions into small utility functions
  • Rename variables and constants to more recognizable names
  • Fix code indenting and formatting for better readability (including improving on long lines of code; I always use word wrap in my editor)

I suppose a lot of this could be avoided by better planning that could lead to actually writing good code to begin with. But I do find the speed at which I can get quick-and-dirty demos running can be a benefit and I don't find the refactoring time is all that bad. Chaos in a warehouse

Chaos can get out of hand
I know working on a large scale project isn't the same as writing small demos and one-off examples, but I think these same principles can be applied to larger projects that have code bases divided into small modules and utilities. There's nothing wrong with stream-of-consciousness coding that leads to awful code and which you can easily tidy up in 10 or 15 minutes immediately afterwards.

But that's the key – don't wait too long to do the refactoring, otherwise the bad code can really pile up and now you have a behemoth of a mess that you're less likely to ever want to go back to.

Do you find you do something similar in your projects? Feel free to hit reply and let me know. I'd love to hear your thoughts.

Now on to this week's tools!


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK