With numerous strategies available for organizing code, including popular options like by component, by toolbox, by layer, and by kind, which approach do you prefer for organizing your code?
Follow the CodeNewbie Org and #codenewbie for more discussions and online camaraderie!
Top comments (8)
I just do my HTML pages with the HTML, then
<script src="URL"></script>
for my scripts and separate stylesheet files for my CSS. Then, to make my code look nice, I use CTRL + SHIFT + I on VS Code (it works because I have the “prettier” extension for VS Code installed).See below:
Before:
After:
It's pretty nice! So, I use file-based organization. Anyone else?
Are these projects just html/css type? static websites
Mostly. I do pretty much only web dev (although I do some PC apps). Not all my sites are static though, I have done some server ones with Node and also Apache 2.
If you mean the prettier extension, it does some other languages as well.
I was confused at first, but I think it's an open call to all projects. Perhaps just best coding practices?
Either way, doesn't hurt to add some if you've got some good ones you do :)!
Here's my perspective from general component organization standpoint (front-end projects)
I try to apply organize the codebase in the following structure:
common - used for common pure components that have no state
layout - for components concerning the layout of the page like footer, navbar, page-layout
modules - self contained modules or pages, it can also be called features, I try to employ domain driven design here
providers - react specific, higher order wrappers that provide either setters or getters
utils - reusable utility functions
services - core functionality classes or functions
assets - all local images and other files
store - used for holding the global store
constants - constant values like resource urls, configuration variables
I just put all the files in the same folder until there's too many of them and then I start organizing. When you have a bunch of different files you know your program will need, it's much easier to come up with a structure that looks organic and makes sense.
Write isolated until it gets messy and at leest somewhat working. Then make it embedable in some large project but still working isolated, then try, try on large scale, fix, bytify, repeat. :D Happy coding!
I am still green 'round the edges. So I can't give you the 411 on everything. But I can say that perhaps the easiest thing to execute at this level is following proper file hierarchies and naming conventions. There's standards for most projects, but you can also follow the leader if you're learning from a tutorial. I'd cross-reference with the docs of whatever you're using though, to double check you're not forming bad habits. Or just look at other projects, scan 'em on GitHub/Lab. You can see what others are doing, and how your fledgling code stands up.
I used to setup projects in their entirety before adding code. But now I'm just adding folders as I go, to reduce file bloat. I think in the future I might utilize the former, but I'm still learning so I'm not hurting over using the latter. I guess the simplest thing to consider is pair likes with likes, and have a place for everything and everything in its place.