Learning Code Organization

Organization - at levels...

Organize your code so that it is easy to read. Reading code is what people do and how they spend so much of their time. And you do not want to compare yourself against the compiler it is so good and fast at reading code... don't try to beat it.

There are different levels of code organization... I guess for the sake of argument let's just agree upon (small, medium, large) with the basic file system working at the medium level. Then inside your file - the small level you have many options (typically in Swift) classes structures and enumerations. And a file may have many of these - when it does one organization construct then becomes the file name. Note the common use case of Swift Extensions and the typical name of <ObjectType>+Extension in the file name.

If you have been around Xcode (Integrated Development Environment - IDE) for some time you will have come across the pragma marks of TODO: FIXME: MARK: seen in comments. Note I believe the colon is a required character in the pragma - but I've never found an official-looking documentation page - have you?

I'm testing out a habit of using a //FIXME: HERE pragma mark to note where in the code base I'm working - so that when I leave and return sometimes days later... I can find the spot that will help me reload that context of - what was I doing...? I love the little bandaid icon that is used for the FIXME notes.

I kinda wish I could add my own pragma marks... and I'm sure if given the opportunity there will be great use cases. For example REVIEW or FEATURE_FLAG.

Files as Modules

A concept that was just sparked in my thinking about organization was that of what is the proper concept of "module" in Swift? In software engineering terms the concept of module is rather vague and ill-defined. Michael Feather's gave the following advice:

"Write tests where you want your module boundaries to be.
Writing them any other place just shifts the boundary -- and your modularization."

I've decided, to start practicing this, and use the File boundary as the basic module demarcation. Let's see how this affects the unit testing... (more to come).

References:

Organizing your code with local packages | Apple Developer Documentation

Creating a standalone Swift package with Xcode | Apple Developer Documentation