A few refactoring tricks that are imperative language agnostic will help you. 1. Early return. --- old if (cond) { logic } else { logic return } --- new if (!cond) return .. logic 2. And instead of nested if. --- old if (cond) { if (cond2) { logic } } --- new if (cond && cond2) { logic } 3. Extraction of pure code. --- old const main = () => { pure calculation side effect pure calculation side effect } --- new // you can unit test calc1 and 2 instead of performing an integration test only on main const calc1 = (...params) => { logic } const calc2 = (...params) => { logic } const main = () => { r1 = calc1(...) side effect(r1) r2 = calc2(...) side effect(r2) } 4. Converting functions that call outside of themselves to ones that are self contained. (Only do this if possible and if it makes sense to, in rare cases in mutable languages you actually must write it in the poor style of external mutation, if you must do that, isolate it as much as you can to mitigate uncontrolled side-effects) --- old let i = 0 const f = i => { i++ } f(i) // i is mutated from f, making f non-deterministic and hard to debug --- new const f = i => i + 1 f(i) // i + 1 is returned but i itself is never mutated out from under you 5. Eliminating global variables and instead using block scoped variables. 6. Reducing mutable variables through higher order functions if applicable, such as using map, filter, and reduce. This simply reduces bug surface area, however, not all imperative languages have performant support for this. ==== General refactoring approach 1. Apply above transformations and more with the goal of concise code that is modular and easy to reason about. Clean code is easier to manipulate that ugly and overly mutable code. 2. Create Integration tests for functionality and unit tests for any pure functions you were able to extract. I recommend using property based testing approaches so you don't have to enumerate a billion example tests. 3. With the tests in place, you start slowly refactoring out with the goal of breaking up everything into self-contained functions. Functions should have 1 responsibility. Meaning that a function should do as few things as possible. The reason for this is so that you can make your system Composable rather than fragile. 4. With your composable building blocks tested, you can then build up more easily. ==== Overall, you should see a massive reduction in the lines of code and your code will be far better if you follow my advice. === Update I have seen very often people using switch statements which is super annoying and bloated. It is equivalent but more terse to use an object instead (atleast in JS, make sure your language you do this in supports hash maps). --- old switch (thing) { case ..: .. case .. : .. .... } --- new (JS syntax) const cases = { 'case1' : () => logic, 'case2' : value or whatever, ... } cases[thing] Alternatively: { 'case1' : () => logic, 'case2' : value or whatever, ... }[thing] // Note: usually you want the cases in your object literal to have a value and not be a function so that you can assign the result to a variable then do further logic // like so: const value = { 'case1' : value, 'case2' : value, ... }[thing] logic on that value ...
@requestfx558513 күн бұрын
Why not use zig build system, "zig init" command helps
@CodingWithTom-tn7nl12 күн бұрын
It's probably better for a large project to use the build system, especially if you have multiple platform targets. For demonstrating things and just getting the code to run quickly, it's more cumbersome. To find the exe, you need to look through folders and normally I just want it to run in the console window. It's mostly preference and I don't feel like I need it. There is barely any different to typing: zig run main.zig vs zig build run
@requestfx558512 күн бұрын
@CodingWithTom-tn7nl valid. I still prefer the build system, zig init and zig build run and it already works. The second you need some module, dependency, c code stuff the build system becomes very useful
@dawid01156 күн бұрын
also zig build system provides caching where zig run does not