Language recognition for .h should default to C, following most common convention

[boazsegev]

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

At the moment, .h files are recognized as C++ files.

This is in contrast to other IDEs as well as the emacs development environment where .h defaults to C.

This is also in contrast with the most common convention for mixed source-file projects (where both C and C++ are utilized), such as the Boost header naming guide.

It is my suggestion that Atom reverts back to it's original default behavior, which is more in line with existing conventions, where .h files are recognized as C.

Details / Rational

The most common community convention is to use .hpp for C++ specific headers (i.e. where namespaces and classes are declared) while .h header files are preferred when the same header can be used also (or only) with C. This SO answer describes the rational for this convention.

It should be noted that this is a controversial subject that was discussed in the C++ official guideline repo. The official C++ guidelines contain a note that states the rational for the use of .h files in C++ is that they can be used together with C (no bold in the original):

This convention reflects a common use pattern: Headers are more often shared with C to compile as both C++ and C, which typically uses .h, and it's easier to name all headers .h instead of having different extensions for just those headers that are intended to be shared with C.

Originally, Atom chose to recognize .h files as C by default, similar to other IDEs.

This meant that lint, clang-format and all other language dependent packages reviewed .h files for C compatibility (vs. C++).

As a solution for C++ syntax highlighting in .h files, Atom changed it's behavior so that .h files are now recognized as C++ by default. This was discussed and merged in PR #156 .

However, time had shown that other packages are negatively effected by this choice of default languages, such as lint, clang-format, etc'.

This change means that errors are either raised or missing (invalid code is seen as valid) when the syntax of .h files is checked, because C and C++ are not the same and have some inherent differences.

Two classic examples for missing and extraneous errors are that the use of char16_t (which is C++ specific) fails to raise an error when used in a C project (though compilation will fail), while void * casting, which is idiomatic C code, raises an error when the .h file is assumed to be C++.

Other examples include inline function issues (code compatibility between the languages) and other details that are language specific (namespaces, classes, extern etc').

It is my suggestion that Atom reverts back to it's original default behavior, where .h files are recognized as C.

People missing C++ specific syntax highlighting can simply change the extension of the file (.hpp is a common extension) while .h will be correctly evaluated for C compatibility.

I hope that you consider this change, which I believe will benefit us all.

I thank you for your consideration, for your time and for a wonderful project.

[alpyre]

As a C programmer, I 100% agree with @boazsegev. Thanks.

[boazsegev]

The Atom minor version bump (1.14.x->1.15.x) might be a good time to introduce this change.

[boazsegev]

Any update on this?

[boazsegev]

@sunjay , I appreciate the participation in the discussion.

Could you explain your reasoning for voting against this?

[sunjay]

I think the default should be configurable. I've seen plenty of C++ projects use .h and it is frustrating having to switch the highlighting back for every file.

[boazsegev]

@sunjay ,

I can see your point. However, I hope you will consider the following three points:

1. While C++ projects can rename .h files to .hpp (or .h++/.hxx), C projects have no other options - C only uses the .h extension.

   So, although it's frustrating for both C++ developers and C developers to switch highlighting (and linter) back and forth, only C++ developers can avoid this frustration while C developers are stuck in an uncomfortable position.

2. Atom is the only IDE that designates the .h to C++ "out of the box".

   All other IDEs follow the older vim convention where .h is a C header (not a C++ header).

   When considering common convention for IDEs, Atom behaves contrary to common convention. This makes Atom behave differently than other IDEs in a way that isn't expected by developers.

   For example (it's just one of many), Xcode uses the UTI list to state that .h is a C header file while either .hxx, .hpp or .h++ are recognized as C++ header file

3. I might point out that the C++ committee also assumed that .h header files are written in C (not C++), so that they can be compiled and shared between both languages.

   I'm not sure there's a good reason to have a C++ development environment that behaves differently than the C++ convention.

I hope you can relate to my point of view and consider changing your vote.

P.S.

I am only discussing the default behavior that comes with Atom "out of the box".

I also think it would be great if each person using Atom could easily configure their own preferences for file extensions, preferably in a project based manner as well as a global manner...

... I think a user can already change the default behavior, but I don't think it can be done per project.

[thomasjo]

Since this can trivially be worked around by user configuration, I'm closing this issue. The recommended way to override the default grammar assignment is to use the core.customFileTypes property, which should be set in your ~/config.cson file;

"*":
  core:
    customFileTypes:
      "source.c": [ "h" ]
  # ...

Hopefully we can use more advanced heuristics in the future, or have this be easier to configure via a GUI, but until that day the above should be sufficient.

[boazsegev]

@thomasjo ,

I hope you reconsider.

The fact that users can apply a local fix doesn't mean the the issue should be closed.

...especially considering that the issue is that the "out-of-the-box" behavior is contrary to community standard and best practices.

Ultimately, I'm a just a thankful guest trying to make Atom even better. I am thankful for all the team behind this wonderful product.

Have a good day.

P.S.

An a side note I should probably point out that I copied and pasted your snippet to a ~/config.cson and it doesn't seem to work.

[bardes]

.h headers really should default to C. I spent a lot of time investigating spurious warnings due to this unreasonable default...