Fuck project setups that

- Have huge nested enterprise folder structures like Java

- Use tons of shell scripts / makefiles

- Have every config file in the root folder

- Don't tell me what I need / how to build

I know some of these can't really be changed easily, but fuck this cluttery mess!

"Don't tell me what i need/How to build"

They are the worst tbh.

How the hell am i supposed to use your software, if i have no idea, what your vague skyrim style description of an instruction means, you dipshit.

src/main/java/com/company/app/app2/event/events/NotifyEvent.java

"Use tons of shell scripts / makefiles"

And without man page 👿

Bonus points for:
- chaotic environment preparation guide on sharepoint, but not linked anywhere, only accessible via search .
- requiring different node version for each module
- 100 maven profiles, half of which does nothing (undocumented)
- multiple modules with cross-dependencies, and first build must be manually completed in special order (also undocumented)
- frontend dependencies so old that you need to manually add them to locally installed libraries

Shell scripts that look like puked out abc noodle soup are a favorite of mine.

Download third party source that is nonstandard and breaks the build !

Fuck basel !

@jonas-w src/main/utils/<made_up_tech_name>/hardware/utils/test/utils.java

And contains a mock class used in the main of a ant call somehow in the CI.

Nope.

rm -rf */
Git add.
git commit --m "delete trash"
git push origin/master --f

I kinda like the config files in top level of the project. I can see instantly what is used by looking at the dotfiles (and wether it's a mess).

@hjk101 Also a lot of tools use the config to identify the project root so you either put the config in the root, add the config location to every command (and try not to accidentally invoke the tool in a subdirectory) or use lots of scripts to add the nonstandard options to the commands of every utility.

And anyway, who lists a project root? I think the last time I scanned through a project root was two years ago. I almost always know whether I need src, test, obj, bin or any of the other files and folders with standard names, and I only ever list the subdirectories.

@lbfalvy yeah that is part of why I like them there. But sometimes you see such a large list of similar tool configs you know the project is a mess.
I've seen a project with a Jenkins pipeline on gitlab just to run some standard tests and to make it worse a yarn lockfile, and a bower config and a npm lockfile.
Obviously nobody cleans anything up here.

@hjk101 Yeah but moving the files out of the project root wouldn't fix that.

@hjk101 Most people cannot identify the used tools by their configs and even if they know some, they likely not know all.

This sounds more like a missing feature to pagas like GitHub, that could show 'Used Tools' and inform potential contributors what they can expect.

This applies regardless of my 'configs not in root' point.

@lbfalvy Considering that configs being in the root is also an arbitrary decision that basically everone went with, I wish all those tools, extensions, .. had from the beginning thought of using a '.config' folder in root ( or other folder ) as a standard option.

Obviously now, this would be a giant effort get it added everywhere.

And yes I know they probably went with root as you just scan every parent, not that a small scan for a '.config' folder would make a huge difference to that though.

@ElectroArchiver They all use the root because it's the most obvious choice. Everyone could've agreed on a custom directory - though forcing all config out of GUI file managers is a bad idea IMO and using a casual name such as config without the leading period runs the risk of derailing the search at /src/loaders/config/ - but ad-hoc standards tend to prefer simple answers and the simplest answer here was to put them in the root.

@ElectroArchiver Anyway, when do you ever need to enumerate a project root?

@lbfalvy Literally every time I look at a project on GitHub & other pages as well as locally

@lbfalvy looks like you misread my first comment. I'm saying that I disagree with the OP on that point...

@ElectroArchiver sounds brittle and doesn't work for in house tools or if one doesn't use a certain central service (like my previous employer)

If you sunny know if you can look it up.
I do find you that it could have been a default '.config' dir. It is what it is. And rather go with the convention instead of fighting it.

@hjk101 Like I stated, it's not something that can be easily changed at this point, that doesn't mean I can't rant about it~

Well, abstract as you read, if you can't for whatever reason (e.g. lack of tests) - at least make notes. Both will help you and other team members in the future. And make sure you're reading the code targeted for human eyes - maybe those makefiles are generated by something like premake, cmake or IDE, same goes for bootstrap scripts. Other than that, we all feel for you. Take a muffin 🧁

I feel you and agree. At least, not every dev can thrive in those jungles and being capable to deal with it happily became my ticket to asking good money and payrises.

Its a trade off, kinda selling the soul to the devil.

Lots of stuff could be fixed.
Quit rolling back

@cprn doing that improvement and helping the company moving forward is the value we bring, it would not jeopardize our jobs.

So fuck Gradle?