Re: [openssl-project] Style guide update -- summary so far

[Kurt Roeckx]

On Mon, Feb 05, 2018 at 08:43:04PM +0100, Dr. Matthias St. Pierre wrote:
> 
> 
> Am 05.02.2018 um 19:13 schrieb Salz, Rich:
> >  
> >
> > Do not put a size after sizeof; do use parens.
> >
> 
> nit: Do not put a /space /after sizeof.
> 
> >  
> >
> > Treat a single-statement with comment as if it were multi-line and use
> > curly braces
> >
> >  
> >
> > if (test()) {
> >
> > /* already alerted */
> >
> > close();
> >
> > }
> >
> >  
> >
> 
> Wasn't there also the suggestion by someone that if one part of an
> if-else statements needs braces that the other part should get some, too?
> 
> if (foo)
> do_this();
> else
> do_that();
> 
> vs.
> 
> if (foo) {
> /* some statements */
> ...
> } else {
> ...
> }

As already pointed out by others, it's mostly already in the style
guide. What is not in it is the combination with a comment:
if (foo)
/* some comment */
do_this();
else
do_that();

And it's been suggested to use curly braces for that.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide update -- summary so far

[Salz, Rich]

  *   nit: Do not put a space after sizeof.

fixed.


  *   Wasn't there also the suggestion by someone that if one part of an 
if-else statements needs braces that the other part should get some, too?

It already says that.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide update -- summary so far

[Matt Caswell]

On 05/02/18 19:43, Dr. Matthias St. Pierre wrote:
> 
> Wasn't there also the suggestion by someone that if one part of an
> if-else statements needs braces that the other part should get some, too?

That's already in the style guide:


Do not unnecessarily use braces around a single statement:

if (condition)
action();

and

if (condition)
do_this();
else
do_that();

If one of the branches is a compound statement, then use braces on both
parts:

if (condition) {
do_this();
do_that();
} else {
otherwise();
}




Matt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide update -- summary so far

[Dr. Matthias St. Pierre]

Am 05.02.2018 um 19:13 schrieb Salz, Rich:
>  
>
> Do not put a size after sizeof; do use parens.
>

nit: Do not put a /space /after sizeof.

>  
>
> Treat a single-statement with comment as if it were multi-line and use
> curly braces
>
>  
>
> if (test()) {
>
> /* already alerted */
>
> close();
>
> }
>
>  
>

Wasn't there also the suggestion by someone that if one part of an
if-else statements needs braces that the other part should get some, too?

if (foo)
do_this();
else
do_that();

vs.

if (foo) {
/* some statements */
...
} else {
...
}


Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Style guide update -- summary so far

[Salz, Rich]

➢ In general we should prefer ossl_assert over assert. Never use 
OPENSSL_assert() in libcrypto or libssl.

Maybe that’s all to put into the guide, then.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] FW: CT Order Confirmation - OPENSSL SOFTWARE SERVICES INC.

[Salz, Rich]

I filed the annual registration for OpenSSL Software Services and paid with the 
OpenSSL credit card.

From: CT Corporation 
Reply-To: "[DO NOT REPLY] CT Corporation" 
Date: Monday, February 5, 2018 at 1:32 PM
To: "rs...@openssl.org" 
Subject: CT Order Confirmation - OPENSSL SOFTWARE SERVICES INC.


Your order details are enclosed
View 
Online






[olters 
Kluwer]




Order Confirmation

CT Corporation




Thank you for your order


We’ve received your request and our experts are already on top of it. You may 
check your order status and view your invoice by logging into your 
account.


Order Summary


CONFIRMATION #: 
10813302
AMOUNT: $225.00
COMPANY: OPENSSL SOFTWARE SERVICES INC.


Ordered By


Rich Salz
44 West St
Reading, Massachusetts 018673712



View or Manage 
Order



Next steps:


  *   Your Annual Report will now be submitted to the state of Delaware
  *   In the unlikely event that your report is not accepted by the state, we 
will contact you to reconcile the discrepancies.
  *   We will notify you by email upon acceptance of the filing by Delaware.
Questions? We're available to assist you at (844) 216-1680 Monday through 
Friday, 9:00 AM to 5:00 PM ET.



Thank you again for your order,
Your Team at CT











CONNECT:
[http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b3c6558af-61f6-4f5d-997b-a9787d2a37c6%7d_fb_24x24_white.png]
 

 
[http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b19213369-075d-4f5a-98d5-ba058e15dcc2%7d_twitter_24x24_white.png]
 

 
[http://images.ctmail.wolterskluwer.com/EloquaImages/clients/CTCorporation/%7b41819dbf-8702-48dc-9694-4c4369726225%7d_linkedIn_24x24_white.png]
 

 

[openssl-project] Style guide update -- summary so far

[Salz, Rich]

A summary of the discussion thread so far.  Not surprisingly, it’s all about 
the whitespace. :)

The descriptions here were written to be understandable stand-alone.  Once we 
come to a conclusion, we’ll wordsmith them into the coding style.

Do not put a size after sizeof; do use parens.

When breaking long lines, if there are Boolean conditionals, put them at the 
start of the line.  Consider doing this consistently, and don’t merge even if 
they fit.  For example:
some_long_condition()
&& short1() && short2()
should be three lines.  Related conditions should be on one line if they fit, 
else given an extra level of indent
some_long_condition()
&& (short1() || short2())
&& some_other_flag != 0

If the expression for an if statement does not fit, indent the continuation 
lines an extra level

if (this_is_true()
&& !that_is_false()) {
code();
….

Try not to break long lines across a function call, but if you have to, indent 
the rest of the parameter list to be after the function’s opening paren.

Remember a blank line after variable declarations (even local ones).

Treat a single-statement with comment as if it were multi-line and use curly 
braces

if (test()) {
/* already alerted */
close();
}

Note that this could end up having “cascading curly” effects.

Arguments inside macro expansions should be parenthesized.

#define foo(a, b)  ((a) + (b))

Free routines should properly handle null; don’t check for null before calling 
a free routine.

When possible, use size_t for sizes of things (including array indicies)

[ Matt said “initialize in the declaration if appropriate; can someone provide 
wording? ]

This is controversial, so maybe drop it.  Don’t use else after return or goto 
unless it makes the flow more clear.

Argument names in function definition should match the declaration, but you can 
use “unused_” as a prefix in the definition for unused arguments.

Use ossl_assert, not assert.  Do not forget to handle the error condition as 
asserts are not compiled into production code.



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project