Coding standards
Security in ResourceSpace
Developer reference
Database
Action functions
Admin functions
Ajax functions
Annotation functions
API functions
Collections functions
Comment functions
Config functions
CSV export functions
Dash functions
Debug functions
Encryption functions
Facial recognition functions
File functions
General functions
Language functions
Log functions
Login functions
Message functions
Migration functions
Node functions
PDF functions
Plugin functions
Render functions
Reporting functions
Request functions
Research functions
Slideshow functions
Theme permission functions
User functions
Video functions
Database functions
Metadata functions
Resource functions
Search functions
Map functions
Job functions
Tab functions
Test functions

ResourceSpace software design principles

When developing ResourceSpace core and plugins please always consider the below principals.

The existing codebase doesn't always adhere to these principals - the contributions from many different developers over the years have meant a mix of coding styles - but the important thing is that we're always moving in the right direction by refactoring as we see fit and peer reviewing new code.

KISS

"Keep It Simple Stupid". A design principle noted by the U.S. Navy in 1960. Don't implement a complex solution when a simple one will suffice. Likewise, don't introduce new technology when reuse of existing technology within the software will suffice. You might be itching to try out a new library, PHP feature, programming paradigm, etc. but in most cases you'll just be adding a steeper learning curve for new developers and making the software more complex to support.

Do one thing and do it well

In the same vein as KISS above. A UNIX design philosophy that for ResourceSpace applies to functions, pages and scripts. We should avoid having a multi-purpose page/function. A series of smaller dedicated and focussed functions/pages are preferable to a large and complex one.

It's far easier to debug a small function with minimal inputs than a 1000+ line behemoth.

YAGNI

"You Aren't Going to Need It!". This refers to the tendency of programmers to add in placeholders, stubs, etc. to build groundwork for future functionality. In the majority of cases this additional development will never happen, usually because the functionality developed was good enough for the majority of use cases. Extra code that's not needed just adds to the "technical debt" of the project, making it more complex to support.

If it's not needed, don't build it.

DRY

"Don't Repeat Yourself". If your code has sections that are identical or very similar to each other the chances are you're doing something wrong. Break it out to a function and handle the differences via parameters.

Duplication is another way to add technical debt. Future changes must now be made in several places rather than just one, and the code is larger and more complex to support.

We set a low threshold for this - even repeating the same block twice means we should break it out to a function (or use a loop or other structure) to avoid duplication entirely.