General Software Application File Structure Advice


The powers that be have decided, despite having a hand full of programmers, that the jr sysadmin (me) is the right code monkey to build a small application for the organization (I guess that's a honor, right?). This is no problem, I can code this thing, however, I'd like it to have the appearance of "professionality" if a programmer reads it. I think the easiest way to trick the programmer species into thinking it is not "dreaded sysadmin code" is to have a nice directory tree.

Like I said, coding a functional 'program' isn't the issue - in fact, the worst part is that I'll need to automate a few more of my prized mindless tasks which give me the appearance I'm very busy (I am) and a valuable employee (debatable, jk) to free up enough time to build this thing.

My experience with programming is mostly task automation, followed by small scale - full stack web development, and bailing out higher ups when they make deals which involve multiple technologies, all using different languages, that have to play together to return a result (Chances nearing 100% why I was selected as the ideal candidate for this project).

This brings me to my question. The project I'll be working on will be a small application which writes to a file, has a GUI, runs on Linux and will be written in PERL (see my position above and only formal programming education in C++ for why PERL). I'd like the only obvious give away a sysadmin wrote the code to be choice of PERL - which could be explainable by a programmer who is a U of I alum - class of '89 (not me) creating it.

Does anyone know of a small scale C or PERL github I can review for quick wins on file structure of applications, books, or advice?

Thank you!

With the highest level of google-fu: "How to write maintainable perl code best practices,"I have found these links:

Oh man - that first link takes all the fun out of writing PERL... don't use $_ or @_ in subroutines... what's the point of perl then?!?!

1 Like

DISCLAIMER: I've never written any perl code.

As a general practice, try to set yourself up so that you can easily refactor. With lack of experience, being able to refactor is going to be very important as over time you'll be able to see how you should organize your code best. Write small functions and avoid globals - those will make it easier to move things to other files. Might want some automated tests, it will allow you to refactor and quickly check if you broke anything.