Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
A major problem of most codebases is formatting imo.
Nobody should need to format code themselves these days. -
I for one can't stand projects where I have to look for repositories myself. IMO projects should have all the required repositories configured correctly, at any point in time.
That, and compilation instructions.
It's really annoying when I have to build the project for the first time and I need a person standing next to me just to explain to me how to compile the thing, which more often than not ends up in that person taking over my peripherals and hunting for the missing repositories/configurations/whatnot.
That's **one of** the things a good project should have. I believe others will fill on the other things. -
Hard to define.
More rules = better code
Nope. Rules can be wrong, bogus or even dangerous.
Eg OOP guidelines - trying to force everything to be OOP usually ends in an clusterfuck of overengineering.
I'd rather say: Collaboration of at least 3 people following a consistent coding style adhering to interdisciplinary language standards.
3 people to have discussions. Single person projects are usually a nightmare.
Duo can be nightmare if one programmer is dominant.
Three to achieve quorum.
Consistent coding style. Note that I like the PSR way of PHP. Yes, it should even dictate what type of whitespace to use. It should explicitly say which features are nonos (Goto, Eval, Error suppression) and which version should be used (eg LTS).
The reason I'm triggered by rules is because many coding guidelines I read had explicitly OOP mixed in - eg. SOLID. This should be seperate.
Coding guidelines - coding style, language specifics, version support. Nothing more.
Interdisciplinary language standards.
Many programmers fall into the pit of "my programming language is so special it's the best".
You should learn from other languages.
PHP eg has it's PSRs - which are nice examples you could realize in other languages and clearly have their origin in other languages projects.
Just because you write in XY doesn't mean you should never take a look at Z - sometimes Z has a better documentation or an RFC that's language agnostic and could be very useful.
While protocols like HTTP are not languages per se, I'd include them, too.
Follow protocol standards. -
Create config files till you need to shift them to their own folder cuz the repo for polluted.
-
Hazarth94734yNot sure Id call it rules per se. A good codebase should follow standards that most people understand. You don't want to be hunting for functions and classes in some complicated clusterfuck
Good naming conventions for classes and folders/packages what have you... A well named class following a standard makes you immediatelly understand what it does without even reading the code.
An *up to date* documentation.. this one I rarely see and In usually the one trying to maintain it... Installation, running, examples... Whatever helps people to get it running asap without a headache. Include a start script if necessary
Code comments... Oh god please add comments if you write something you even assume might be confusing for someone...
Code that's easy to use correctly and hard to missuse... Strong typing, immutability, dependency injections... If you make your code easy to use correctly by others, and hard to use incorrectly, the whole codebase will be cleaner with any number of people
Related Rants
How do you define a good codebase?
From my experience, a good codebase is a codebase that is strongly opinionated.
More rules = Better code
Honestly, i am sick of maintaining codebases written by sickos who think they are hot shit for doing what nobody else does
rant
code
software
engineering