google / google/styleguide

google-c-style.el should require cc-mode for proper statement-cont line break indentation

Open
#426 2 comments 0 reactions 0 assignees View on GitHub
lang:cpp
Dominant language
HTML
Stars
39.6k
Forks
12.9k
Avg merge
42m
Merged PRs (30d)
15

Description

I don't believe that the Google C++ Style Guide ever explicitly spells out any rules for indenting line breaks for long arithmetic expressions, but I suspect that the formatting is supposed to follow the recommendations for [Function Calls](https://google.github.io/styleguide/cppguide.html#Function_Calls) and [Function Declarations and Definitions](https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions):
> wrap the arguments at the parenthesis, or start the arguments on a new line indented by four spaces and continue at that 4 space indent.

The Emacs `google-c-style` conditionally defines the association list `c-offsets-alist` in a way that suggests this intent:
https://github.com/google/styleguide/blob/6271f3f473ceb3a7fef99388a3040903b1a145f1/google-c-style.el#L118-L124

When loaded with a minimal
```elisp
(require 'google-c-style)
(add-hook 'c-mode-common-hook 'google-set-c-style)
```
The alist element evaluates to `(statement-cont nil nil ++)` because `(fboundp 'c-lineup-assignments)` is `nil`. So, Emacs indents a long arithmetic expression as follows:

```c++
double x = 7.9
+ 3.0;
```
The `c-lineup-assignments` function is defined after CC-mode is loaded, but is not provided by `cc-defs`, as far as I know. Adding `(require 'cc-mode)` to the top of `google-c-style.el` results in `(statement-cont nil c-lineup-assignments ++)`, which then indents arithmetic operations with line breaks similarly to function calls and declarations:

```c++
double x =
7.9 + 3.0;
```

```c++
double x = 7.9
+ 3.0;
```

Is this the intended outcome?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.