[petsc-dev] coding style

[Barry Smith]

> On Aug 15, 2016, at 7:42 PM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
> 
> 
> Got it.  I will get all the code fragments in the developer doc that
> are not meant to be deliberately wrong fixed tomorrow; at least
> that code will be compliant...  :)
> 
> Then its onto fixing bqpip.
> 
> Was there a final say on the Hessian/Jacobian matrix when they are
> modified?  Were we adding a "dirty" bit or was I changing my code
> to not modify those matrices?

   Changing email to petsc-dev since this is a general PETSc/TAO issue.

   This is why we don't wait months to fix something :-) I have completely forgot the context you are asking  about.

   I think the general issue comes up when a problem is linear and the user just wants to set and forget the matrices while when the problem is nonlinear the user needs to reset values into the matrix anyways so it is fine for you to change the matrix internally. Unless there is a way for the user to explicitly indicate the system is linear your code cannot know if it needs to make a copy of the matrix. 

   In TS we have typedef enum {TS_LINEAR,TS_NONLINEAR} TSProblemType; and TSSetProblemType() that can be used to indicate if the matrices can be changed or not (though I don't think we use it in this way, we have an open issue https://bitbucket.org/petsc/petsc/issues/135/memory-optimization-for-ts

   I think you should start by having a flag that indicates if it is safe to modify the matrices associated with the TAO object and if not safe keep a backup copy.

  Barry



> 
> Todd.
> 
>> On Aug 15, 2016, at 6:09 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> 
>> 
>>  Todd,
>> 
>>> On Aug 15, 2016, at 10:26 AM, Satish Balay <balay at mcs.anl.gov> wrote:
>>> 
>>> Todd,
>>> 
>>> Forwarding this to Barry.
>>> 
>>> Satish
>>> 
>>> On Mon, 15 Aug 2016, Munson, Todd wrote:
>>> 
>>>> 
>>>> I'm going through the developer documentation.  There seems to be
>>>> a few things missing from the coding style.
>>>> 
>>>> For example, in function prototypes, is it:
>>>> 
>>>> PetscErrorCode MyFunction(char *,const int *,int);
>>>> 
>>>> or
>>>> 
>>>> PetscErrorCode MyFunction(char*,const int*,int)
>> 
>>  The second one because the preference is to not have unnecessary space.
>> 
>>>> 
>>>> 
>>>> Same thing in the definitions:
>>>> 
>>>> PetscErrorCode MyFunction(char *c,const int *i,int j)
>>>> {
>>>> }
>>>> 
>>>> or
>>>> 
>>>> PetscErrorCode MyFunction(char* c,const int* i,int j)
>> 
>>  The * should always be attached to the variable.
>>>> {
>>>> }
>>>> 
>>>> The same questions apply with * replaced by [].
>>>> 
>>>> 
>>>> Next is in the types for variables.  Are pointers grouped
>>>> separately or together with the type:
>>>> 
>>>> int   *i,j,*k;
>>>> 
>>>> or
>>>> 
>>>> int   *i,*k;
>>>> int   j;
>>>> 
>>>> If grouped together, should they be ordered with pointers first
>>>> and the others later?
>>>> 
>>>> int   *i,*k,j;
>> 
>>   There is no preference on the above; the pointers do not have to be on their own line.
>>>> 
>>>> On the next topic, do you use
>>>> 
>>>> char    *blah;
>>>> 
>>>> or
>>>> 
>>>> char*   blah;
>>>> 
>>>> when there is only one of them?
>> 
>>  * belongs on the variable
>> 
>>>> 
>>>> I have the same issues with the typedefs.  Sometimes there is
>>>> 
>>>> typedef struct _EH* EH;
>>>> 
>>>> and other times
>>>> 
>>>> typedef struct _EH *EH;
>> 
>>  Here the * belongs as in the first case
>>>> 
>>>> 
>>>> My personal thought is to be consistent and use char * with a space 
>>>> everywhere, but you tell me.  I will then go and fix the developer
>>>> documentation to be consistent with the style guide as a test of
>>>> my branch management.
>>>> 
>>>> Todd.
>>>> 
>>>> 
>>> 
>> 
>