I know it matters for class libraries, but does it matter in projects that are not class libraries, e.g. console applications or GUI applications?
What's the difference if I use public or internal or private when it's a console application and it won't be reused?
Is it worth the effort to add access modifier in such cases?
I mean specifically access modifiers of types (classes, enums and structs).
Yes they do matter.
Writing good code is all about completing units of functionality. A complete unit of functionality can be fully tested and never require any changes in future.
This is why it's good practice to split code into libraries and classes. Even in your own code, even if you aren't writing a library. If you can split the code up into smaller parts and limit what the compiler will let you do with each part your life will become easier.
Sure you can write all your code in a single massive function with gotos and it will work. You can further argue that because it works and only you are ever going to look at it, nothing else matters.
But don't kid yourself that it's faster or easier. That's like riding a horse everywhere because you haven't learnt to drive.
When your whole program consists only of one assembly and contains no other class lib, there is actually no difference between public and internal in C#, so this distinction does not matter. Leaving out any keyword here (so keep every class internal by default) works well.
Note that as soon as one adds a second lib like a unit test assembly, which references the "main" assembly, one needs to start thinking about where to add public. Usually this is nothing which causes a big headache: just add public to every class where it is required to make the unit tests working.
private for classes and enums only matters if you are working with a class or enum nested inside another class, so the question you should ask first here is: do you need nested classes?
The answer to this is mostly independend from if you are building a class lib or not. Assumed you need a nested type, you don't loose anything using the private scope the same way you use it on methods: as a default for everything which is only needed inside the class. In fact, when you don't add the private keyword, nested types are automatically private, and in case you need the type to be visible elsewhere, you need to add public explicitly.
So the effort to make nested types "private" is zero, and the benefit should be clear: it stays easier to reason about the impact of future changes to your code, since you know a change in a private code unit is restricted to the outer scope.
In short: don't overthink this. Simply use the default scope for any class when you are developing only a one-assembly-program, and add public or internal to your classes when it becomes necessary. That will automatically lead to sensible visibilities.
The current answers are both good and come from different perspectives, here is one more.
Do I need the "the" in my first sentence? Not really.
current answers are both good and come from different perspectives, here is one more.
...is just as intelligible, although it sounds unfinished, like someone might have been rushed, or didn't consider the statement fully.
So does this "the" lacking sentence need rework?
Some will say yes, because it has left a detail underspecified and has wriggle room for misinterpretation, or apparent lack of consideration.
Others will say no, because in the current context it works, the intention is obvious, and the tooling supplies the correct interpretation.
My answer is: Who is going to read this?
I could go on, just try to list everything/everyone that reads the source code files, or anything derived from them and ask how it impacts them now, in 5 weeks, a year, 5 years, when you are no longer there.
It is eye opening and sometimes jaw dropping just how large your actual audience is/will be.
Now have you communicated with each of these individuals, and programs successfully?
There will be times when being explicit, and pedantic is important in order to communicate an important point clearly.
There will be times when being terse, and implied is important in order to communicate an important point clearly.
To help me decide when I should be explicit or implicit I lean on Shannon's Information Theory: The most meaningful information should take the most space, the least meaningful should take the least.
Just to note, the rule of thumb about meaningful information taking the most space, that is within limits, its a statement about signal to noise:
Generally, if a shorter phrase does the same job in terms of communication as a longer phrase, that shorter phrase should be preferred because longer phrases usually dilute the signal.
access modifiers seem redundant in such casesThat is the same as saying "It doesn't need an access modifier since I don't need it to be public", at which point the suggested duplicate answers your question.