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.

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

        • Anastasia Kazakova says:

          That’s correct. We are currently implementing MSVC debugger on top of LLDB, including natviz. Hope it will be available later this year. v2019.2 seems realistic for now.

  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.

Leave a Reply

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