const char* typedefs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

const char* typedefs

Paige DePol
I was doing a bit of a code audit when I had a thought...

Why not create a typedef for 'const char*' to save some space in the code:

typedef const char* l_str

There were already some functions that began with 'l_str' for conversion or
for Lua versions of C string utility functions, so it seemed logical.

As there were 697 matches in my current code base and the typedef is 6 or 7
letters shorter, depending on the position of the *, that saves nearly 5000
characters. Yes, not really a big deal, but what it does do is help things
fit into 80 columns better by providing extra space in functions with a lot
of 'const char*' parameters, or variables, or typecasts. I have made this
change to my code base and it really does make a number of functions tidier
due to the extra space.

I did some searching and generally it is advised to not hide pointers behind
typedefs, unless the data type is opaque. I would say that C strings should
qualify for this treatment and in my opinion it really works well.

I also note that Lua itself has a typedef that also hides the pointer:

typedef TValue *StkId;

I don't see any reason why this shouldn't be an okay thing to do, but in
my searching I mostly found warnings about not doing it... usually for other
data types, and not const char*... so thought I'd check to see what opinions
there were, or to see if I am violating some unwritten coding style rule! ;)


I also found a potential missing 'const' in gc_state() from 'ltests.c':

  static const char *statenames[] = {"propagate", "atomic", "sweepallgc",

Shouldn't that be as follows to match all other static lists of C strings:

  static const char *const statenames[] = {"propagate", "atomic", "sweepallgc",


Unless there is some serious reason for not typedefing 'const char*' I think
I will go with it as I do think it is an improvement in code readability!

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Paige DePol
Paige DePol <[hidden email]> wrote:

> typedef const char* l_str

Nobody has an opinion on this style of typedef?

The question may seem noob'ish, but really I am just curious if
anyone else uses a typedef like this or if I am violating some
sort of unwritten rule when coding in C.

Hacking on Lua has been a lot of fun, but is also a return to
the C language to me, so I am not necessarily up to speed with
all the things you should and shouldn't do.

My online searching seems to go both ways with people saying it
is fine and others saying it is a horrible thing to do. Mostly
people are against hiding pointers, but as C strings are just
pointers to arrays of 'const char' I guess I don't see hiding
the pointer as being a major issue.

I have converted my codebase to use it, and I do like it, I
was just wondering if this is something that other developers
will take one look at and curse me for doing it? I do get the
impression this may just one of those style things, like where
you place opening braces and the like.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Dirk Laurie-2
2018-02-05 22:04 GMT+02:00 Paige DePol <[hidden email]>:
> Paige DePol <[hidden email]> wrote:
>
>> typedef const char* l_str
>
> Nobody has an opinion on this style of typedef?
>
> The question may seem noob'ish, but really I am just curious if
> anyone else uses a typedef like this or if I am violating some
> sort of unwritten rule when coding in C.

As far as I am concerned, whatever is not deprecated by Kernihan
and Plauger [1] is good C style.

[1] https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Josh Simmons
In reply to this post by Paige DePol
On Mon, Feb 5, 2018 at 9:04 PM, Paige DePol <[hidden email]> wrote:
> Nobody has an opinion on this style of typedef?
>
> The question may seem noob'ish, but really I am just curious if
> anyone else uses a typedef like this or if I am violating some
> sort of unwritten rule when coding in C.
>

It's not really an unwritten rule or anything but you have to consider
"what concrete value am I achieving with this change" and "what will
another programmer see when they look at this code".

const char * is an exceedingly common and standard way of passing
null-terminated string arguments, anybody who has programmed C before
will be able to recognise it immediately so all that you achieve by
hiding it behind a typedef is obfuscation because now a reader has to
investigate what a l_str is to understand the code.

Considering that Lua's code (and code in general) is read far more
often than it is written, saving a few characters is not a worthwhile
tradeoff.

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Dibyendu Majumdar
In reply to this post by Paige DePol
On 4 February 2018 at 11:25, Paige DePol <[hidden email]> wrote:
> Why not create a typedef for 'const char*' to save some space in the code:
>

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Paige DePol
In reply to this post by Dirk Laurie-2
Dirk Laurie <[hidden email]> wrote:

> As far as I am concerned, whatever is not deprecated by Kernihan
> and Plauger [1] is good C style.
>
> [1] https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style

That is a very nice list to adhere to, thanks for sharing!


Dibyendu Majumdar <[hidden email]> wrote:

> https://www.kernel.org/doc/html/v4.10/process/coding-style.html

Given they advocate for 8 space wide indentation I'd think that they
would want to save themselves some space! I find it funny that some
of their rational was just literally "K&R" and nothing else.

They also like putting the * for pointers on the variable name, which
is what Lua does as well. My previous experience with Obj-C usually
put the * with the type, which makes more sense to me, but I am now
used to putting it with the var name so either way works.

In the kernel coding style document they state the following:
In general, a pointer, or a struct that has elements that can reasonably
be directly accessed should never be a typedef.

A C string isn't a struct so it has no elements, and as it is always
passed as a pointer to an array of characters I thought this typedef
would be appropriate. I do find a number of examples for it in C++
code online... but not a lot of examples in C code, which seems odd.


Josh Simmons <[hidden email]> wrote:

> const char * is an exceedingly common and standard way of passing
> null-terminated string arguments, anybody who has programmed C before
> will be able to recognise it immediately so all that you achieve by
> hiding it behind a typedef is obfuscation because now a reader has to
> investigate what a l_str is to understand the code.

Sure, but isn't that the same for any typedef you don't know the first
time you encounter it? There are typedefs for other long names as well
such as "typdef unsigned int uint" and the like. Although the Linux
kernel people don't like that either.

Lua has "typedef TValue *StkId" which is used to represent the TValue
pointer as an opaque type. Aren't C strings just opaque types as well?
I guess I just saw creating the typedef for 'const char*' in the same
light as the typedef for StkId.

Now I am a bit torn between using this typedef and not using it. ;)

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

nobody
On 2018-02-05 23:50, Paige DePol wrote:
> They also like putting the * for pointers on the variable name, which
> is what Lua does as well. My previous experience with Obj-C usually
> put the * with the type, which makes more sense to me, but I am now
> used to putting it with the var name so either way works.

That's because in C

    Foo* bar, baz;

probably isn't what you want[1], and with

    Foo *bar, baz;

it's easier to notice.

-- nobody

[1]  bar is a pointer, baz isn't.

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Tim Hill


> On Feb 5, 2018, at 8:00 PM, nobody <[hidden email]> wrote:
>
> On 2018-02-05 23:50, Paige DePol wrote:
>> They also like putting the * for pointers on the variable name, which
>> is what Lua does as well. My previous experience with Obj-C usually
>> put the * with the type, which makes more sense to me, but I am now
>> used to putting it with the var name so either way works.
>
> That's because in C
>
>   Foo* bar, baz;
>
> probably isn't what you want[1], and with
>
>   Foo *bar, baz;
>
> it's easier to notice.
>
> -- nobody
>
> [1]  bar is a pointer, baz isn't.
>

Which is an argument in favor of the typedef, since:

typedef const char *l_str;
l_str bar, baz;

DOES work correctly.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Paige DePol
In reply to this post by nobody
nobody <[hidden email]> wrote:

> On 2018-02-05 23:50, Paige DePol wrote:
>> They also like putting the * for pointers on the variable name, which
>> is what Lua does as well. My previous experience with Obj-C usually
>> put the * with the type, which makes more sense to me, but I am now
>> used to putting it with the var name so either way works.
>
> That's because in C
>
>  Foo* bar, baz;
>
> probably isn't what you want[1], and with
>
>  Foo *bar, baz;
>
> it's easier to notice.
>
> -- nobody
>
> [1]  bar is a pointer, baz isn't.

Yes, attaching the * to the variable name does make declaration statements
like those much easier to parse... and as such I have moved my *'s from the
type name to the variable. It was easy to adopt and retrain myself to use
this style given that the Lua code base uses it as well.

For my 'const char*' typedef I went with 'l_str' to match the existing style
used by Lua... though I suppose I could also just use 'ccstr' for a pretty
obvious abbreviation for 'constant character string'.

While C strings themselves are not technically opaque data types I do think
it could be argued we treat them as such. We simply pass around pointers to
the various functions that work on strings, and because they are declared
'const' we're also not supposed to modify the contents ourselves directly.

I have done some more googling and if you search for "typedef const char"
as an exact phrase the typedef comes up in code bases from a wide range of
companies, from Apple to Microsoft, and a bunch of open source projects.

I also seem to find it referenced quite frequently on Google Books in a
number of books about programming in C++ for some reason. I guess I don't
see 'hiding' the C strings behind a typedef as a bad thing, so for now I
think I will try using the typedef, though I will change it to 'ccstr'.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Forrest Christian (List Account)
In reply to this post by Paige DePol
I figured I'd add my $0.02:

As an acquaintance of mine which is in charge of a team who writes development tools including compilers likes to express in various ways, identifiers in c only last the first few fractions of a second when compiling c code.   It doesn't matter to the compiler whether an identifier (and especially the name of a typedef) is a single character long or hundreds of characters long.  The sole reason for using an identifier is to put a name on something.   And, as many many programmers are likely to tell you (and especially once you start learning about topics such as clean code and code smells), it is best for an identifier to be spelled out, not subject to interpretation, and doesn't necessarily need to be short.   The only space you're saving is on the disk of the developer (or anyone else who deals with the source code), and that is cheap and plentiful.

In addition, I personally find typedefs which just reiterate the type to be useless.   If you're going to go to the bother of defining a type, define a type, not just an alias for a existing type.

Something like "typedef const char *" ccp  is horrinbly wrong on so many levels.  Better would be something like "typedef cost char * constCharPtr" but even that is just regurgitating what you already are saying.    Far better is to describe the use something which describes the data itself, i.e. "typedef const char * constNullTerminatedStringPtr" if that's what it is used for.  If it's pointing to a different type of data, use an appropriate type name for that.

That way when someone encounters something like

constNullTerminatedStringPtr yourVariableName

It's obvious your intent.

To head off some nit-picking about my suggestions above:   I want to be clear about my intent here:  I'm trying to point out the advantages of well thought out typedef (and other identifier) names, not state that the above are necessarily well thought out.  They might not be.  In particular, I'm not sure whether I'd include Ptr in the name or not.   I've also known myself to add 'Type' at the end of the identifiers for typedefs which some people like and some hate.  Once could also argue about where to place 'const', etc.   But, those discussions are secondary to the key point here:  use identifiers which are clear in their intent and are easy to read, and don't just regurgitates the underling C code.   

I'd highly recommend reading about refactoring and code smells and the like.   Also the video series by Robert C. Martin is excellent if you have access to them for free through some method (such as safari books online).
 

On Sun, Feb 4, 2018 at 4:25 AM, Paige DePol <[hidden email]> wrote:
I was doing a bit of a code audit when I had a thought...

Why not create a typedef for 'const char*' to save some space in the code:

typedef const char* l_str

There were already some functions that began with 'l_str' for conversion or
for Lua versions of C string utility functions, so it seemed logical.

As there were 697 matches in my current code base and the typedef is 6 or 7
letters shorter, depending on the position of the *, that saves nearly 5000
characters. Yes, not really a big deal, but what it does do is help things
fit into 80 columns better by providing extra space in functions with a lot
of 'const char*' parameters, or variables, or typecasts. I have made this
change to my code base and it really does make a number of functions tidier
due to the extra space.

I did some searching and generally it is advised to not hide pointers behind
typedefs, unless the data type is opaque. I would say that C strings should
qualify for this treatment and in my opinion it really works well.

I also note that Lua itself has a typedef that also hides the pointer:

typedef TValue *StkId;

I don't see any reason why this shouldn't be an okay thing to do, but in
my searching I mostly found warnings about not doing it... usually for other
data types, and not const char*... so thought I'd check to see what opinions
there were, or to see if I am violating some unwritten coding style rule! ;)


I also found a potential missing 'const' in gc_state() from 'ltests.c':

  static const char *statenames[] = {"propagate", "atomic", "sweepallgc",

Shouldn't that be as follows to match all other static lists of C strings:

  static const char *const statenames[] = {"propagate", "atomic", "sweepallgc",


Unless there is some serious reason for not typedefing 'const char*' I think
I will go with it as I do think it is an improvement in code readability!

~Paige





--
Forrest Christian CEO, PacketFlux Technologies, Inc.
Tel: 406-449-3345 Address: 3577 Countryside Road, Helena, MT 59602
[hidden email] http://www.packetflux.com
  

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Grey Knight-2
On Tuesday, February 6, 2018, 8:06:35 AM GMT, Forrest Christian (List Account) <[hidden email]> wrote:

> it is best for an identifier to be spelled out, not subject to interpretation, and doesn't necessarily need to be short.

I agree with this.  Saving a few thousand characters of source by contracting names has at most zero value to me, I think.

> Also the video series by Robert C. Martin is excellent

Provided you can stomach the zany antics. >_>


Also, on the subject of Type* foo, bar; declarations, my hygiene for dealing with this is just to make separate declarations for each pointer variable.
I don't want to have to remember the "correct" position for the asterisk because in my experience any procedure dependent on programmers "just remembering" things is doomed to failure. :-)
I'm happy to spend some extra newlines to simply remove that particular problem altogether.

--
GK

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Paige DePol
In reply to this post by Forrest Christian (List Account)
Forrest Christian (List Account) <[hidden email]> wrote:

> I figured I'd add my $0.02:

Thank you for your feedback! I have done some reading about code smells[1]
and I get the impression that using such typedefs may come down to a style
choice versus a serious problem in and of itself.

I do my utmost to try to keep my code clean, obviously I am not perfect but
I really do try to learn from my mistakes, and the mistakes of others, and I
try to not be obstinate for no good reason.

Not using typedefs to create simple type aliases is in style guides[2], but
I really didn't find much evidence of it being a code smell. The verbose and
informative WikiWikiWeb[3] site does have a rule[4] I have heard of before
which is similar: The more a variable is used the shorter it should be.

On the main Code Smell page of WikiWikiWeb they make some observations about
how the approach to code smells can be pragmatic or purist. Which means that
depending on your view a code smell either hints at possible bad practice
for a pragmatist or is a sure sign of bad practice to a purist.

They also have this phrase on that same page which I found amusing:
"Rules are for the guidance of the wise and the obedience of fools."

The idea of saving space was not in terms of physical space on media, but
rather that of source code line length. Also, typing "ccstr" is just faster
than typing "const char *" all the time as well... coders are often lazy! ;)

That laziness is probably why typedefs exist for the various unsigned data
types as well... 'uint' is much nicer to type instead of 'unsigned int'.

I have a bunch of source code from various external projects sitting around
on my drive so I did a quick grep of it all to see if I could find some
examples of the 'const char *' typedef... LLVM, clang, emscripten, a number
of Apple source files, and a bunch of Windows source files all hit.

Some of the examples of things people think are code smells that I can't
really agree with were using typedefs to mask 'struct' from types. Another
person advocates not using the macro preprocessor because it hides the
code behind a macro, so you should really use functions instead.

There were more examples, but it is getting late as I've really got to get
some sleep... I've been reading about code smells now for far longer than
I anticipated. I didn't expect this subject to be quite as controversial
as it appears to be... but then I guess that also doesn't surprise me! ;)

~Paige

[1] Did a Google search for "code smell examples" and read a good number
   of the sites that were more than just a list of terms.

[2] https://www.kernel.org/doc/html/v4.10/process/coding-style.html

[2] http://wiki.c2.com/?CodeSmell

[3] http://wiki.c2.com/?VariableNameSameAsType under Criticisms



Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Dirk Laurie-2
In reply to this post by Forrest Christian (List Account)
2018-02-06 10:05 GMT+02:00 Forrest Christian (List Account)
<[hidden email]>:

> In addition, I personally find typedefs which just reiterate the type
> to be useless.   If you're going to go to the bother of defining
> a type, define a type, not just an alias for a existing type.

The bigger picture matters too.  The typedef adds a layer of abstraction
and of self-documentation.

For example, size_t, ptrdiff_t, etc all just define an alias, but you know
what they will be used for.

In llimits.h you find Instruction to be a typedef for unsigned either
integer or long, depending on a precompiler variable.

If Paige had chosen to emphasize that aspect, rather than the
code-golfing point of view, more people might have agreed sooner.

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Daurnimator
In reply to this post by Paige DePol
On 6 February 2018 at 03:21, Paige DePol <[hidden email]> wrote:
> The idea of saving space was not in terms of physical space on media, but
> rather that of source code line length. Also, typing "ccstr" is just faster
> than typing "const char *" all the time as well... coders are often lazy! ;)

I would not use a typedef for `const char*`:

  - A *huge* number of APIs take a const char*, including C standard library
    functions e.g. strlen, strcmp, fopen
  - char* (and variants) have a special exclusion from C aliasing rules: it's
    important to know when something is only accessed normally as a char*.
  - I'm not concerned about line length very much. I can fit 3 120 column
    terminals side by side on my screen...

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Pierre Chapuis
On Tue, Feb 6, 2018, at 19:00, Daurnimator wrote:

>   - I'm not concerned about line length very much. I can fit 3 120 column
>     terminals side by side on my screen...

You are lucky. I just checked and I can fit 190 columns total
on my screen. Anything more and I cannot read the code
without straining visual effort. And that's when I use my 27"
monitor, on my 13" laptop I don't go over 120 columns.

That being said, I agree with not using typedef here. If types
are too long to fit on a single line, just use more lines, for instance
putting the return type on its own line like in KNF.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Sean Conner
It was thus said that the Great Pierre Chapuis once stated:
> On Tue, Feb 6, 2018, at 19:00, Daurnimator wrote:
>
> >   - I'm not concerned about line length very much. I can fit 3 120 column
> >     terminals side by side on my screen...
>
> You are lucky. I just checked and I can fit 190 columns total
> on my screen.

  422 at work ... about 180 at home.  

> That being said, I agree with not using typedef here. If types
> are too long to fit on a single line, just use more lines, for instance
> putting the return type on its own line like in KNF.

Or each parameter on its own line:

int dump_memorys(
        char       *dest,
        size_t      dsize,
        void const *data,
        size_t      size,
        size_t      amount,
        size_t      offset
)

  -spc (Who likes vertically aligned code ... )

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Paige DePol
In reply to this post by Dirk Laurie-2
Dirk Laurie <[hidden email]> wrote:

> 2018-02-06 10:05 GMT+02:00 Forrest Christian (List Account)
> <[hidden email]>:
>
>> In addition, I personally find typedefs which just reiterate the type
>> to be useless.   If you're going to go to the bother of defining
>> a type, define a type, not just an alias for a existing type.
>
> The bigger picture matters too.  The typedef adds a layer of abstraction
> and of self-documentation.
>
> For example, size_t, ptrdiff_t, etc all just define an alias, but you know
> what they will be used for.
>
> In llimits.h you find Instruction to be a typedef for unsigned either
> integer or long, depending on a precompiler variable.
>
> If Paige had chosen to emphasize that aspect, rather than the
> code-golfing point of view, more people might have agreed sooner.

Yes, I could have expressed my initial idea better than just "ooh less
characters". At the time I was thinking it would be nice to type less and
there are other typedefs that do similar things (the unsigned types).

However, as I was thinking about it during this conversation I also realised
that whenever I see "const char*" I just think "C String". A shorter name is
always nicer, and "ccstr" also concisely summarises the object to me.

Obviously "ccstr" is quite a bit more informative than my initial idea of
using "l_str". However, while the general consensus does seem to be against
the idea I am not entirely sure I am convinced to not to use the typedef.

While 'const char*' is not an object or an opaque type, in this particular
case, I don't think it hurts to think of it in this manner. If I am going
to think of 'const char*' as a discreet item then why not give it a name.

Honestly though I will have to give this idea some thought, and I will do
some more reading about the subject. Thanks again for your feedback and
advice on the subject everyone, I really do appreciate it!

~Paige





Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Paige DePol
In reply to this post by Sean Conner
Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Pierre Chapuis once stated:
>> On Tue, Feb 6, 2018, at 19:00, Daurnimator wrote:
>>
>>>  - I'm not concerned about line length very much. I can fit 3 120 column
>>>    terminals side by side on my screen...
>>
>> You are lucky. I just checked and I can fit 190 columns total
>> on my screen.
>
>  422 at work ... about 180 at home.  

I can get about 190'ish as well in my IDE comfortably. Which gives me two
side-by-side 80 column windows with a bit of extra space. Also the project
manager bit takes up some room as well. Sadly, my eyes are not as good as
they used to be and as I get older my fonts get larger.


>> That being said, I agree with not using typedef here. If types
>> are too long to fit on a single line, just use more lines, for instance
>> putting the return type on its own line like in KNF.
>
> Or each parameter on its own line:
>
> int dump_memorys(
>        char       *dest,
>        size_t      dsize,
>        void const *data,
>        size_t      size,
>        size_t      amount,
>        size_t      offset
> )
>
>  -spc (Who likes vertically aligned code ... )

I think that style would take a lot of getting used to, though I guess
I can see how for functions with a lot of params it is easier to read!

~Paige



Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Sean Conner
In reply to this post by Paige DePol
It was thus said that the Great Paige DePol once stated:
>
> However, as I was thinking about it during this conversation I also realised
> that whenever I see "const char*" I just think "C String". A shorter name is
> always nicer, and "ccstr" also concisely summarises the object to me.

  Okay, so "ccstr" is "typdedef char const *ccstr" [1] but does that imply
that "cstr" is "typedef char *cstr"?  If so, then there's only a single
character difference between two different types so typos might be hard to
decern (maybe---it may be that the compiler might catch instances of ccstr
when a cstr was meant, but not so much the other way around).

  My only other argument against it is that "char *" is *so* idiomatic for a
"string" that it seems silly to hide it just to save some typing [7].

  -spc (Who realizes that "const char *" is more idiomatic than
        "char const *" but does the later anyway ... )

[1] Why "char const" and not "const char"?  Because "const" actually
        binds to the right (except when it's at the leftmost position).  I
        was fond of doing stuff like:

                const char *const p;

        which defines p as a constant pointer to a constant character, but
        it doesn't read that way.  Instead:

                char const *const p;

        *does* read that way.  I use that style mostly for global variables,
        such as this one [2]:

                extern void (*const c_conversion)(FILE *const restrict,FILE *const restrict);

        which is a constant pointer to a function, said function takes two
        FILE *s which are themselves constant [3] and guarenteed not to
        point to the same thing [4].  Sometimes, globals are unavoidable,
        but I try to make them read-only as much as possible [6].
       
[2] https://github.com/spc476/mod_blog/blob/6a92de05304987ae9d37d9e833a53523883a555d/src/globals.h#L69

[3] My thought when I wrote that at the time was to show that the
        parameters were *not* arrays [5].  My thinking these days is to show
        array parameters via '[]' which is more explicit in intent
        (exception being C strings, which are technically arrays).

[4] That's what "restrict" is for.

[5] Because C makes it too easy to conflate pointers with arrays.

[6] Yes, they're defined in a single file:

        https://github.com/spc476/mod_blog/blob/6a92de05304987ae9d37d9e833a53523883a555d/src/globals.c

        and there, they aren't const.  I have to set them somewhere.  It's
        only to the rest of the code that they are defined as constant.  It
        makes it a bit easier to reason about the code.  There are a few
        globals left that aren't "const" and I'm still trying to work on
        those.

[7] We read code more than write it.  Spend the extra few seconds
        writing it.

Reply | Threaded
Open this post in threaded view
|

Re: const char* typedefs

Sean Conner
In reply to this post by Paige DePol
It was thus said that the Great Paige DePol once stated:

> Sean Conner <[hidden email]> wrote:
>
> > Or each parameter on its own line:
> >
> > int dump_memorys(
> >        char       *dest,
> >        size_t      dsize,
> >        void const *data,
> >        size_t      size,
> >        size_t      amount,
> >        size_t      offset
> > )
>
> I think that style would take a lot of getting used to, though I guess
> I can see how for functions with a lot of params it is easier to read!

  While the above is from code I wrote [1] I had to spend some time looking
for an example of the above.  I try to write function with as few parameters
as possible, partly because of the "creeping width" issue, but it's also a
"code smell".

  -spc

[1] https://github.com/spc476/CGILib/blob/master/src/Dump/dump_memorys.c

12