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).

  • @gnat it's not a question about methods and fields but types.
    – Konrad
    Mar 19, 2019 at 15:28
  • @Konrad: The principle of access modifiers remains the same regardless of whether you're adding them to methods, fields or types. At least in scope of the qsuestion you are asking here.
    – Flater
    Mar 19, 2019 at 15:30
  • @Flater no it's a different question. When you reference some class library you don't see all the types, but you don't reference console applications and the question is about that. To me, access modifiers seem redundant in such cases.
    – Konrad
    Mar 19, 2019 at 15:32
  • 1
    @Konrad: access modifiers seem redundant in such cases That 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.
    – Flater
    Mar 19, 2019 at 15:34
  • @Flater yes so access modifier is irrelevant . Thanks
    – Konrad
    Mar 19, 2019 at 15:39

3 Answers 3


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.

  • 1
    All great 'till you got to the metaphor. Most folks nowadays would find learning to ride horse much more difficult than learning to drive. ;-) Mar 19, 2019 at 21:32
  • 1
    yes when you add a metaphor there's always the chance that some people won't understand it.
    – Ewan
    Mar 20, 2019 at 15:48

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.

  • 1
    this is an OK answer, but it could do with a metaphor or two
    – Ewan
    Mar 20, 2019 at 15:50

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?

  • Yourself
  • Yourself in 5 weeks?
  • Yourself in 5 years?
  • Your team
  • Your team in 5 weeks?
  • Your team in 5 years?
  • Your team when you have left?
  • The compiler with the current specification, on your current platform
  • The compiler with a newer specification, on your current platform
  • The compiler with the current specification, on another platform
  • The compiler with a newer specification, on another platform
  • An interpreter...
  • A Static analysis tool/s...
  • Search/Regex tools
  • Your IDE
  • ...

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.

  • If a function must be public, that is an important detail, be explicit.
  • If a function must be private, that is an important detail, be explicit.
  • If a function could be private or public, that is an irrelevant detail, be implicit (if you can, or be as under-specific as possible in the language).

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:

  • Noise being irrelevant details, and
  • Signal being the important details.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.