Say no to messy code

You ever look through someone else's repo and not able to make heads or tails about what does what? Even if you're a beginner looking at advanced code, you should be able to at least marginally tell what is what. If not, this isn't necessarily a sign of a lack of skill, or knowledge, but more so the failure of the developer to properly style their code and name their functions and variables descriptively enough (or at the least leave descriptive comments).

To that end, I’d like to lay out some pointers and a base style to give you an idea how code should be structured.

Indentation and line spacing

Proper indentation and line spacing is probably one of the biggest issues developers have, especially new developers. If you are new, or looking to improve your code, I implore you to read on.

Not formatting your code correctly can be disastrous for debugging and just development in general. If you cannot read your own code easily, you have a major problem. This is especially true for other developers and employers that may view your code. Trashy code is marginally OK if your project is entirely private and only you will ever have access to it, but it's a bad practice to even use in any environment.

This problem should be nipped in the butt before writing our first line of code, before we even print "hello world" to the console. Good habits start now.

Each language has its own style guidelines, this will focus on Javascript, which in a lot of languages you can apply a similar style.

So let's build out a fictious React component.

Global imports go first, and stay at the top. Module imports are at the top, and project imports go below. Separating project imports and module imports with a space can be helpful if there ends up being a lot of them.

import React from 'react';
import styled from 'styled-components';

import Profile from '../views/Profile';
import { useAppSelector } from '../../redux/app/hooks;

Global true constants go next (variables that aren't meant to be changed/modified).

import React from 'react';
import styled from 'styled-components';

import Profile from '../views/Profile';
import { useAppSelector } from '../../redux/app/hooks;

const ID = 10ad4J;
const MAXVALUE = 10;

Followed by other constants.

import React from 'react';
import styled from 'styled-components';

import Profile from '../views/Profile';
import { useAppSelector } from '../../redux/app/hooks;

const ID = 10ad4J;
const MAXVALUE = 10;

const Container = styled.div`
   background-color: #ffffff;
`;

Next goes functions, components, and/or CSS-in-JS.

import React, { useState } from 'react';
import styled from 'styled-components';

import Profile from '../views/Profile';
import { useAppSelector } from '../../redux/app/hooks;

const ID = 10ad4J;
const MAXVALUE = 100;

const Container = styled.div`
   background-color: #ffffff;
`;

const AComponent = () => {
   const isUserLoggedIn = useAppSelector(state => state.user.loggedIn);

   return (
      <Container>
         <Profile auth={isUserLoggedIn ? ID : false} />
      </Container>
   );
};

Lastly, we put our exports.

// Spaces inside brackets, outside of JSX.
import React, { useState } from 'react';
import styled from 'styled-components';

import Profile from '../views/Profile';
import { useAppSelector } from '../../redux/app/hooks;

const ID = 10ad4J;
const MAXVALUE = 10;

const Container = styled.div`
   background-color: #ffffff;
`;

// Single props don't get parens.
const AComponent = props => {
   const [user, setUser] = useState({});

   return (
      <Container>
      {// No spaces in brackets inside JSX}
         <NavBar loggedIn={user}/>
      </Container>
   );
};

export default AComponent;

There's more rules to it than this but you get the general idea hopefully, and can easily expand.

Modularization (or code splitting)

Each module should do one thing and one thing only, just like a function. This should be a practice done with all areas of code. Putting all code in one file may work, but its unreadable for one, and when you need to update that particular branch of code, it is difficult to isolate for debugging and development.

Code splitting is the process in which you split code into smaller chunks, components, and bundle them together into modules and import the components where they are needed. These modules then form packages. Ideally, this process would make files easier to read, and keep your code clutter free. But it should also be like reading code like a book.

If done incorrectly, you could result in a broken flow where a user reading through the project has to jump back and forth between files to understand what is fully going on.

Instead, what should happen is that first your app calls all the needed data, maps the response into a form we can actually work with efficiently, and only providing the data that we need for our program to work. Your file then may call on some helper functions (ideally stored in an outside file) to do some further voodoo magic, followed by returning the processed data into an object that we can work on in the other files. A file should ideally only have one output, although it could take input from several things as needed.

Knowledge in OOP design generally helps with this idea, and can be used in functional programming as well.

Proper Project Directory Structure

Being able to read code is only half the battle. Being able to find where a particular file is a quarter of the other half, and being able to determine what that file is for is the rest. Directories should be named for the content they contain, and files should be named for the data they process, mostly for what the file does.

What directory structure you follow will ultimately depend on the stack used. This is the basic structure of most React apps (or at least my personal projects anyways):

Root
|_.ideconfigfolder
|_node_modules
|_public
  manifest.json
  index.json
  robots.txt
  ...other files including images and what not
|_src
  |_assets
  |_components
  |_utils
  |_redux
  |_styles
  App.jsx
index.jsx
...global project configs and ignores.

I've taken after the atomic design principle. My Structure looks something like this:

If you take anything from this article, develop a readable style, improve, and stick to it. If you're unsure what's readable to you is readable to others, share a sample of your code (a good sample size so they can get a good feel for your style), and get some feedback.