Question About Style

General
,
1

The default code style configured by Alire requires using a space after the name of a function, procedure, or array and before the open parenthesis. For example:

X := Some_Function (A + Some_Array (B));
--                ^space          ^space

I realize this is also widely used by AdaCore. However, I’ve never been a fan of this style, and I would normally write the code above without the spaces.

The Ada Quality and Style Guide is a little inconsistent on this issue. The text says that spaces should be placed on the outside of parentheses except not immediately after a function call. This suggests the code as I wrote it above is right. However, the examples in the style guide are wildly inconsistent on this point, sometimes even in the same example (and sometimes even only a couple of lines apart!). That should probably be fixed.

Also, some authors, notably John Barnes, do not use the space in the examples in his books.

I’m prepared to conform to a community style, even reformatting my existing code to do so, but I want to be sure there is a strong agreement within the community about it. My question is: to what extent do people use/expect those “extra” spaces?

Thanks!

2

Ideally there would be half-spaces at the places you indicate.

2 Likes
3

Since 2000 I’ve used -gnaty for GNAT style, and I can’t see why anyone would want to use anything else. That includes line length :slight_smile: - I like 2 Emacs frames side by side on my laptop.

I know the RM omits the space between the subprogram name and the paren; it’s wrong.

I’m partly conditioned by the way the Rational Environment worked: you could format code as you liked while working on it, but once internalised (‘semanticised’, I think) it was formatted the way the computer thought best.

I understand this is the way the upcoming gnatformat tool works.

3 Likes
4

I just use whatever the default formatter is in whatever language I’m using. I personally don’t like 3 space tabs, but that’s the Ada default and what GNATformat does by default, so /shrug.

Using GNATformat defaults has been great. I don’t have to configure anything when setting up a project and it mostly “just works” and is one less thing to worry about.

My issues with GNATformat is that there are no “stop/start formatting” markers like with clang format or gnatpp. There are also a few bugs with it causing it not to match the warnings emitted using the default Alire config, which is a problem since I use -Werror. Using it with the VS Code extension on Linux also often causes both ada_language_server processes to sit at 100% CPU, so I’ve been using a script with the following:

alr exec -P1 -- gnatformat

# Workaround a current bug in gnatformat which doesn't properly format generics
# with "is (<>)" and removes the space between them.
find src -name rfl-args.ads | xargs sed -i -e 's/is[(]/is (/g'
1 Like
5

My preference…
Some_Function( Parameter );
…but let’s be honest: it’s a really stupid thing and ought to be done as per individual, automatically, because the code is not stored as text, but as meaningful structures stored in a database.

1 Like
6

Your example uses my (by far) prefered presentation.

I suppose that’s because whatever interfere with the natural silhouette of the word impairs reading for me.

Some_Function( is visually closer to Some_FunctionI than to Some_Function.

I may be rationalizing what is just an habit, but at least it gives me a general guideline to answer those presentation questions. For example, I am against removing underscore for the same reason.

7

In the videos I saw of Ichbiah, Barnes, and Firth presenting the newly christened Ada language at the Ada Launch (1980-12-10), one of the presenters stated that Ada used English reserved words so that the resulting code would read like English text. This implies some other assumptions about how Ada should be used: Identifiers should be English_Words, and most punctuation should be used as it is in English.

There is also an explicit preference for American English: terms such as “parenthesis/parentheses” are used for ( and ) and “apostrophe” for ’ (ARM-83 2.1); “Color” in ARM-83 14.7; and so on. Since native American-English speakers make up more than 60% of all native English speakers, American English seems like a good choice when addressing an international audience.

Since in English, the parentheses around things (parenthetical information) are adjacent to the information they enclose and separated from the rest by a space, as in this example, that should be how they are formatted in Ada, unless there is good reason to do otherwise. I have not seen a good reason to do otherwise for simple pairs of parentheses.

In English, sequences of parentheses do not occur; when one needs nested parentheses, one cycles through brackets and braces and back to parentheses, so sequences of the same kind of parenthesis do not occur. In Ada, such sequences are common, so one must decide how to format them. I find it hard to keep track of such sequences. In something like

Some_Function (Some_Array (Another_Function ((A + B) / C))))

do I have the correct number of right parentheses? Sometimes I am lucky enough to be able to use a tool that helps me, but other times, such as reading the above, that is not the case. I find it easier, though still difficult, if there is a space between them

Some_Function (Some_Array (Another_Function ( (A + B) / C) ) )

The only other way I can think of right now where I differ from common English use is spaces around colons. The reading advantages of aligned colons over a list of declarations seems to outweigh the normal English usage.

They’re not “extra”; they’re normal (English) usage.

2 Likes
8

In my code I handle it this way:

Some_Function
(  Some_Array
   (  Another_Function
      (  (  A
         +  B
         )
      /  C
)  )  )  )

So, the last one was too many.

1 Like
9

I feel like I’m reading Lisp code, it almost gives me a headache :slight_smile:

I’m sorry, this may be satisfying because beautiful and well aligned, but this certainly is not readable! (at least for me)
I am strongly in favor of a syntax as close to English as possible.

The argument of the mismatching closing parenthesis do not carry much weight : is there someone on this forum using an editor that doesn’t show you immediately the problem?
And even in that case, it won’t compile. This is a great virtue of Ada, let’s take advantage of it.
I wouldn’t sacrifice readability for almost no gain in development time or robustness.

1 Like
10

I’ve worked on multiple systems that do not have a smart editor. I’ve tried to train myself not to rely on them as much due to this.

As a data point, neither your way nor Dmitry’s way is very readable to me, but then I really believe readability is a very subjective standard.

11

Mismatching parenthesis is very different from missing or extra parenthesis. No editor can catch that. Though editors highlight matching parenthesis it does not help much.

1 Like
12

A long time ago, I was an avid reader of the Psychology in Programming Special Interest Group. I retained that on most subjects, scientific studies have been conducted, even though the computer science community is not aware of them, (and sadly language designers do not take them into account). I’m pretty sure readability has already being defined (not so easy) and measured.

But I’m also pretty sure that Dmitry’s presentation vs RM vs AQS has no impact worth wasting our time, and I could live without frustration with -gnaty.

My limit is uppercasing all keywords, like in Ada first time, or in Pascal world (and even worst, enforcing it, like in Oberon).
This is too ugly for me! :smiley: :smiley:

13

I thought vim was everywhere, is it a myth?? :slight_smile:

14

It is indeed a myth. And even if you have VIM, there is no guarantee it will have Ada mode I have found out.

I’ve been bitten by both assumptions quite a few times now.

I’ve seen a few studies on the topic (not sure if they are the same as if you are referring to though), but they generally only reflected a small reference group and not reflective of the programming world at large (which I am not sure is possible given the variety of backgrounds/cultures). Also most were from like 20-30 years ago I think (like 1990s+ era), so they would be out of date now adays. Do you know of any up to date studies per chance?

15

Or in my case title-casing some keywords. Naming no names.

16

Which particular keywords?

17

Some_Function( Some_Array( Another_Function( (A + B) / C) ) )
Which is where the style I showed can help a bit: by having the function/array open-parentheses as (visually) part of the name, and putting spaces in the parameters, it gives a little break and I find the eyes more able to spot the balancing.

Yep, I’ve had several systems where I was stuck with nano, vi, or emacs.

*cough*

I like to do initial caps on subprogram-keywords & their begin/end, packages and their begin/end (and Private), extended-return (and it’s matching end), Generic, and Type.

1 Like
18

I think I used to have to turn Emacs’s show-paren-mode on, but it seems now to be on by default.

I’ve also seen a hint that in vi % over a paren will show the match?

19

Sorry, I am now an amateur computer scientist, I can no longer be interested in everything, I have to choose my battles! :slight_smile:

20

There seems to be a lot of misunderstanding about my comments on sequences of the same kind of parenthesis, so I guess I didn’t express myself well. I was not talking about getting it write when writing, but about ease of understanding when reading code, justifying adding spaces between them because it makes that easier.

Kazakov sacrifices ease of understanding to get ease of counting parentheses. OneWingedShark sacrifices ease of understanding for no apparent gain.

How does your use of such an editor help you read the code that I posted?

Ada has never done that. ARM-83 uses all caps for identifiers, but all small for reserved words.