Rack code style

I’ve added an Artistic Style options file .astylerc to the Rack repo’s root which auto-formats Rack’s source code. (See its documentation.) Most of Rack’s source code follows this style, but I’m considering tweaking it a bit, running the script on the entire repo, and reviewing changes.

How destructive are the following changes?

  • Change Foo *foo to Foo* foo
  • Change Foo &foo to Foo& foo

Any other suggestions to the code style?

1 Like

I prefer Foo* / Foo& because it puts the type information on one side of the space. Too bad about Foo foo[], but that’s just the way C is.

Rack’s source for me is easy to read and (mostly) comprehend; no complaints about the existing style.

1 Like


Okay, went ahead and applied code style. Couldn’t think of anything else to change.

Foo* varA, varB;
What am I declaring?:upside_down_face:
The * is an attribute of the variable, not of the type.

1 Like

My code style disallows declaring multiple variables in the same statement.


Foo* foo; is the style used by straustroup.

perhaps enforce curly brackets for if statements and other blocks? weird bugs can come in here. a famous apple ssl bug was due to missing these brackets

Evaluated that but decided against it. It inflates the codebase by 1000 lines, and it’s a lot of vertical screen space when working with a lot of if () return logic. Also, Apple’s bug would be solved by the auto-indenter.

Coding styles have the advantage of being easy to automate. I disagree mostly with the choices outlined above but I have had to make MASSIVE changes in coding style every time I change jobs, so whatever seems right to you.

I am not a Rack developer anyway, just interested in the project. I’ve read enough of the source to be a fan of the design and implementation choices, I’ll overlook your terrible taste in code formatting :wink:

Not interested, thanks. Interested only in my question at the top.

1 Like

I’m used to both styles, I don’t regard that change to be destructive.

I stick with K&R, I am aged.:older_adult: