CLion 2019.1 EAP: naming conventions


Here comes a new CLion 2019.1 EAP build 191.5532.20! Get it from our website, Toolbox App, or via a snap package (if you are using Ubuntu). The patch will be available shortly if you are using the previous EAP build.

Download CLion 2019.1 EAP

Naming Convention

Naming is a non-trivial decision every developer makes daily. It can improve the readability of our code or ruin it completely. This is why naming conventions have been created: to help developers follow standard paths when selecting names for various identifiers such as global/local variables and functions, types, parameters, classes, and so on. Known libraries, game engines, and other notable pieces of code usually follow some predefined schemes their authors agree on and recommend that all contributors use as well (if the project is open source).

We’ve recently asked our followers on Twitter: “Which naming styles do you usually use in your C++ projects?”. The answers were very diverse; here are just a few:

The reason we asked is, obviously, our desire to improve CLion and help our users keep the preferred naming convention. This EAP showcases our first steps in this direction.

We keep listening to your feedback on Twitter and in our issue tracker (check the subtasks under CPP-15439) and plan to improve this area further before the 2019.1 release.

Let’s see what great new things you can do in CLion!

How to configure? Code Style settings

A new tab is now available in Settings/Preferences | Editor | Code Style | C/C++, called Naming Convention. Here you can configure the preferred style for namespaces, macros, classes, enums, functions, parameters, etc.

You can select the style (lowercase, camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, or UPPERCASE). You can also set a custom prefix or suffix (for example, you can use ‘E’ as a prefix for all Enum types).

Most likely we’ll be adding more options here – for example, it’s already obvious that template parameters are currently missing (CPP-15445). Note also that the settings are global per IDE for now. If project-wide settings are important to you, feel free to up-vote CPP-15446.

You can also select the naming style (and other code style settings) from the predefined scheme:

Note that these schemes are used for indents, spaces, and other formatting options at the same time, so not all of them actually include any naming rules. We may add more schemes in the future.

How does CLion respect the naming style?

CLion respects the naming settings provided and uses them in the following features:

  • Autocompletion.
  • Code generation, including live templates.
  • Extract/Inline function and Introduce define refactorings.
  • Quick-fixes which generate code, such as add parameter to constructor, change function signature according to call, and some others.

naming quick-fix

In addition, if you’d like CLion to enforce a naming convention more actively, turn on the new Inconsistent Naming inspection (Settings/Preferences | Editor | Inspections | C/C++ | General). CLion will highlight the problematic names and will suggest a quick-fix to replace all usages with a more accurate name:
naming quick-fix

Other improvements

More notable changes in this EAP build include:

  • For those who use Remote Development mode in CLion, IPv6 is now supported. Please check the corresponding ticket (CPP-14264) for details on how to enable it.
  • CMake 3.13.4 is bundled.
  • We do recommend that our users use the experimental Clangd-based language engine (turned on by default). However, if you experience any issues with it, you can now easily turn it off: use Enable clangd server in Settings/Preferences | Languages & Frameworks | C/C++ | Clangd. And please don’t forget to report any issues you encounter with all the logs to us.

That’s it. The full release notes are here. Download and try the EAP build today. We are looking forward to your feedback!

Download CLion 2019.1 EAP

Your CLion Team
The Drive to Develop

This entry was posted in Announcement, Early Access Preview and tagged , , , , . Bookmark the permalink.

27 Responses to CLion 2019.1 EAP: naming conventions

  1. Anton says:

    Thanks for fixing the header highlighting issue. However, “override” and “final” keywords are still not highlighted if the function body is in the cpp file. This issue was introduced first when you started experiments with clangd many months ago.

  2. jack says:

    when will debugging for vc support come, thanks

    • Anastasia Kazakova says:

      It’s in development now, but it requires more time as we implement the debugger from scratch, including nat.viz. support, etc.

      • Roman Popov says:

        I’ve seen you had LLDB MSVC support job openings some time ago. Do you implement natviz support for LLDB?

        I think there is a problem with C++ in general that there is no standard solution for portable type pretty printers. As I remember there were related bugs in Clion tracker, to provide a capability to edit pretty printers. Probably this is a good area where Clion, as a cross-platform C++ solution, can contribute to isocpp.

  3. Andrzej Głuszak says:


  4. David Harvey-Macaulay says:

    Note that there are variants of camelCase/PascalCase, for example ‘acronyms as words’:

    XmlParser instead of XMLParser.

  5. Kirill Sapozhnikov says:

    Any chance for fixing this regression: CPP-13081 ?
    It has been here since last May and will celebrate it’s first birthday soon.

    • Anastasia Kazakova says:

      We’ll check, but the problem is that it’s technically not a regression. There is some technical bug that we can’t currently fix easily. My question here – is it still there if you switch to using ClangFormat in CLion?

      • Kirill Sapozhnikov says:

        Yes, it is still present. As for regresion, it used to work fine, it is marked as regression in Youtrack, so it’s a regression from my point of view. The reasons may be different, difficult and obscure (and I understand it), but from the user’s point of view it is not something you postpone for 9 months. Thanks for clearing this up.

        • Anastasia Kazakova says:

          We marked it as regression mostly because it’s indeed the regression from user’s view, however in the code it’s not and for now it’s not that clear how to deal with that, mind we have to balance this with performance and currently solutions don’t fit our requirements in this direction.

          We are sorry you feel disappointed here and fully understand you. We’ll do our best to think about some quick solution.

  6. Andrew Smith says:

    I’m super excited about clangd syntax highlighting; using the built-in language engine caused a lot of inconsistencies (as there are many cases where the built-in language engine things something is wrong when it isn’t).

    However, I am seeing a lot of problems with this EAP build and the last EAP build. In many instances, I will now get no syntax highlighting or errors (even though clangd errors worked fine in 2018.3). Sometimes this fixes itself after a long time, but often it does not fix itself until (it seems) certain errors in the file are fixed. Other times, I will see complete syntax highlighting one minute, and then as soon as I make a change, all syntax highlighting (and errors) will disappear, as if clangd just stopped working. Sometimes when I undo the change and save, I will get back syntax highlighting and errors (even when manually reverting the change does not bring it back). I don’t see any patterns here, other than that this happens more often when a change is made that causes some kind of compiler error.

    I know that these are EAP builds and that instability is expected, but I just wanted to make sure you were aware of these types of issues. Currently I need to turn off clangd for errors and syntax highlighting in these EAP builds.

    • Helge Penne says:

      Could this be related to this regression?

      Also, there is this ugly bug in the new clang format support:

      You really should not release 2019.1 until these are fixed. New releases should fix old bugs, not knowingly introduce new ones.

      • Anastasia Kazakova says:

        Clang Format issue is in progress. Another regression is under investigation. We definitely work on regressions and EAP program is specially created to catch such situations at users side as we can’t cover all the use cases in testing. Thank you

    • Anastasia Kazakova says:

      Andrew, Can you please report the cases to our issue tracker? EAP is especially intended to catch such bugs, as our automatic tests and manual testing still can’t cover all the configurations/use cases. So your feedback is much appreciated! We’ll do our best to fix the issues, once we can reproduce them on our side. That’s why I ask for a sample/description in the tracker. Thank you.

  7. Helge Penne says:

    It seems that changes to fix clang-format formatting for autocomplete-generated code has broken autocomplete for #include statements:

    This is very serious regression that will aggravate lots of users unless you fix this before the final release.

  8. Henry says:

    Many people use the m_ prefix for private member variables, leaving public members unchanged, and sometimes s_ for static member variables. Is it possible to enforce m_ and/or s_ for this system?

    • Anastasia Kazakova says:

      You can enforce the prefix now, but can’t distinguish between private/public, static.

      • Henry says:

        Does that mean its not possible to enforce a difference between public private member variable naming convention distinction? Is there at least work being done to add an option to enforce that? m_ for private members is an incredibly widespread convention, and it would be nice to at least have a prefix difference between public and private members (or just public and non public members).

Leave a Reply

Your email address will not be published. Required fields are marked *