Member Avatar for cored0mp

I'm working on an application, certainly not my first. Some aspects of my coding background are quite informal, for example I have only a rudimentary understanding of source code repositories.

Take library formation, for example? I'm reasonably proud that my source is of sufficient quality and organization to pass an audit - no spaghetti code here. But I'm relatively unprincipled when it comes to breaking source out into smaller files.

How are you as coders able to discipline yourself to do this? What criterion do you use to split things out? What goes and what stays?

  • 3 Contributors
  • 2 Replies
  • 147 Views
  • 8 Hours Discussion Span
  • Latest Post Latest Post by Dani

Dani AI

Generated

Good question — the decision should be practical, not religious. The simplest rule of thumb: split code into a library only when you have a clear, testable boundary that will be reused or needs its own release cycle. That keeps you from premature extraction and gives the library a real purpose.

A quick checklist to decide whether to extract:

  • Reuse: the code will be used in more than one project or component.
  • Stability: its public behaviour can be specified and kept reasonably stable.
  • Independence: it has few app-specific dependencies and can be tested in isolation.
  • Size/complexity: it’s nontrivial to reason about inside the app (too large or too many responsibilities).
  • Ownership/versioning: you want separate versioning, CI, or deployment cadence.
  • Duplication: identical logic appears in multiple places.

A safe extraction workflow:

  • Add or improve tests around the target code first.
  • Define a small public API and mark internals as private.
  • Create a package layout and CI, then move code and tests into it.
  • Publish to an internal registry or PyPI with semantic versioning and update the app to depend on the new package.
  • Monitor for breakage, then iterate.

Example package layout:

mylib/
    mylib/
        __init__.py
        core.py
        helpers.py
    tests/
        test_core.py
    pyproject.toml
    README.md

Watch out for common pitfalls: extracting too early (over-generalizing), tight coupling to app internals, and then maintaining many tiny packages. For solo projects it’s often fine to keep things in-repo until the boundary proves useful; for teams, codify the extraction checklist into code review criteria so decisions aren’t just personal preference.

Given ’s emphasis on auditable code, use tests and a small public API as gatekeepers. Balance ’s valid point about author preference by formalizing when a split happens. For MVC-style setups like ’s, utilities and cross-cutting concerns are the usual first candidates. For packaging details, see the Python Packaging User Guide and follow Semantic Versioning.

Recommended Answers

All 2 Replies

Member Avatar for rproffitt

As to splitting functions each to a file, never adopted that because I am the author and it was my choice. Now this was all C code, not C++ so with each language we followed the rules that worked for us.

In other words, standards are great since we have so many to choose from. For instance, indentation was one I told them to take a hike on. That rule would change with every manager. It wasn't worth it to change the code base to meet the new standards. If they wanted it changed, we'd ask for additional hours (money) which shut down the request quickly.

commented: thanks, I appreciate it! +0
Member Avatar for Dani

I code in PHP with MVC architecture. Each model and controller are their own class and there is one per file. Views are PHP templates, also one template (which typically represents either a full HTML page, or a large, reusable segment of an HTML page) per file.

commented: This. Follow what works best for each language and of course your preferences. +17
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.