Golang type naming convention

[drago....@gmail.com]

Hello,

I want to have the following struct:

type NameType string

type AgeType    uint32

type Name struct {

   Name NameType

   Age    AgeType

}

Struct fields have to be public. Is this adding "Type" after each typedef inline with the Golang philosophy?

Thank you.

[David Anderson]

No, adding "Type" makes the types look weird, so unless there's a specific reason why you must do it, don't.

Additionally in this case, I wouldn't typedef the names and ages at all. Adding the extra indirection adds no information, compared to name+builtin type.

type Person struct {

  Name string

  Age int  // No need for int32, unless you're planning on people being >200 years old, int will work just fine.

}

- Dave

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[drago....@gmail.com]

This was just a simple example. 

The idea is that would have:

type VolumeType float64, and then use this VolumeType in the whole program. Later when I want to change the type, I will change only this typedef. Now there is go tool for such refactorings, but I didn't looked at it till now.

Moreover it is useful this way:

// This is actually tells me what this structure is

map[AgeType]NameType 

//And this is not

map[uint]string

I come from C++ world, that there this is the way. Is there Go-way of doing these things?

[Rob Pike]

So would
map[Age]Name

The word 'Type' is superfluous. Go the language doesn't have a
"philosophy" of naming, but the community has conventions and the
convention here is not to make names longer by saying things that are
clear without being said. The name 'i' is fine for a loop variable;
the name 'iterationCounter' is not as good.

-rob

[Dragomir Ivanov]

I would like very much to name my types without "Type", but then I can't use that name anywhere else:

type Age uint

type Name string

type Person struct {

   Age_ Age /// Can't use Age for the field name

   Name_ Name /// Can't use Name for the field name

}

That is why I fell back on the "Type" suffix. I guess with more mature IDE ( with sane code completion) this issue will drop out, e.g. I will see the field types in the suggestions.

[Rémy Oudompheng]

Le 3 sept. 2013 00:01, "Dragomir Ivanov" <drago....@gmail.com> a écrit :
>
> I would like very much to name my types without "Type", but then I can't use that name anywhere else:
> type Age uint
> type Name string
> type Person struct {
>    Age_ Age /// Can't use Age for the field name
>    Name_ Name /// Can't use Name for the field name
> }
>

You can name your fields Age and Type, there's no reason why you couldn't.

Remy.

[Dragomir Ivanov]

Indeed, I didn't tried that, assuming it will work as in C/C++. Thank you Remy.

[Antoine Grondin]

It's very painful to go through obscure data declarations/manipulation in some projects.  For instance where there's a distinction between `CustomerID` and `LegacyCustomerID`, but it's not named the same through the program by the many devs who went through it, and then you're there trying to make sense of which form of `ID` is this raw `int` supposed to be.  If you typedef it, the compiler will tell you and you won't be able to mix the two `CustomerID` and `LegacyCustomerID` without being yelled at.

Or where a `string` is used to define a `merchantSKU` and a `networkSKU` and whatever other form of `SKU` you have within the domain of your problem.  And then you assume that this particular variables is an `alienSKU` but in this specific case it's actually a `lochnessSKU` but you don't know about this new SKU and just mix the two together by mistake.  

Type safety is great. It's super lightweight to do that in Go, whereas in other language (Java!) you need to create an ugly wrapper class to get some type hints from the compiler.  So I think OP's right in his path to declaring types.  Of course anything can be abused.

[Matt Harden]

Struct fields do not have to be public.

Types are in a different namespace from struct fields, and each struct has its fields in a different namespace from other structs.

There is no difficulty with naming a struct field the same name as its type, in fact I would consider it quite reasonable in some cases.

I would not add the suffix "Type" or any other suffix to all your type names. That is definitely not idiomatic Go.

In my opinion it can be very useful to name your types based on their meaning in the program's domain - for type safety and documentation, for example. But I wouldn't overdo it. It's OK to use int if the thing is really an int and unlikely to get confused with other ints in your program.

[Kevin P]

I'm not saying you should ever do this but you can do this if you wanted... but don't really do it. http://play.golang.org/p/QxY_pctrm9

[Kevin P]

Anonymous structs are the shit. http://play.golang.org/p/TSTe-OJYBt

[Mateusz Czapliński]

 I think you could make it even shorter:

    type Age uint
    type Name string
    type Person struct {
        Age

        Name
    }

/Mateusz.

[Kyle Lemons]

On Mon, Sep 2, 2013 at 4:52 PM, Antoine Grondin <antoine...@gmail.com> wrote:

It's very painful to go through obscure data declarations/manipulation in some projects.  For instance where there's a distinction between `CustomerID` and `LegacyCustomerID`, but it's not named the same through the program by the many devs who went through it, and then you're there trying to make sense of which form of `ID` is this raw `int` supposed to be.  If you typedef it, the compiler will tell you and you won't be able to mix the two `CustomerID` and `LegacyCustomerID` without being yelled at.

When I do code reviews, if I see a basic type given a new name, I will raise it as an issue unless it improves the readability and maintainability of the program.  If it makes it easier to write correct code, e.g. it makes it so you can't pass a CustomerID as a LegacyCustomerID, that's fine.  If it has methods attached, it's fine.  If it's there to document the precise semantics of values of that type, that's fine.  If it's there just to save keystrokes, though, that's generally not fine.

[you...@z505.com]

Realize this is an old post.....

Other languages like Delphi solve this problem by going

    type TAge int
    type TName string

The "T" prefix is short, terse, and doesn't bloat up the code with "TypeThis" or "TypeThat" or "ThisType" or "ThatType

However, this is not a go convention..I'm just mentioning it because other languages have had these same debates and issues, and solved them long ago. (or rather created a subjective flamewar of who prefers what).

I find this sort of stuff confusing:

    var Name Name

Compared to:

    var Name TName

The "T" terse letter makes you know for sure what is the type and what isn't, as doubling up on name name or age age can look weird, confusing, and you may mix up what is the type and what is the variable if you are used to reading C..

    var Name Ooops

How do you know if Ooops is the type, or Name is the type?  If you are used to reading C code, you could accidently read it as the type being Name since in C code the type comes first.. not the variable...

This problem exists when reading function declarations too, when you are multitasking from C code to Go code.. so this is more clear:

    var Name TOoops

Now Ooops is obviously the type and there is no guessing, so it is no longer and ooopsy daisy I mixed up which was type and which was var name..

True, the "T" takes one extra character... whether it is worth it or not is something to consider. Just an idea. But be warned that if some Go programmer reads your code and you use "T"prefix convention.. you might get laughed at as being a delphi programmer trying to turn Go into Delphi! ;)

Overall I prefer short names wherever possible and find a lot of Delphi and Java code with OverWordyLongNamesThatAreTooRedundant

I also agree that using "i" is always better than "iteratorLoopCounter" but sometimes "idx" is nice too if you are calling strings.Index() or and need to store an index position, and have already used up "i" elsewhere in the function. There was some computing science book written about how we should never use "i" because it doesn't tell you anything, but I strongly disagreed with the book and stopped reading it when they tried to justify their long names that didn't really help the code become cleaner.

Regards,
Lars
(Again, I realize this was an older post from years ago but still relevant)

 

[Egon]

On Monday, 21 September 2015 17:07:19 UTC+3, you...@z505.com wrote:

Realize this is an old post.....

On Monday, September 2, 2013 at 3:00:51 PM UTC-6, drago....@gmail.com wrote:

Hello,

I want to have the following struct:

type NameType string

type AgeType    uint32

type Name struct {

   Name NameType

   Age    AgeType

}

Struct fields have to be public. Is this adding "Type" after each typedef inline with the Golang philosophy?

Thank you.

Other languages like Delphi solve this problem by going

    type TAge int
    type TName string

The "T" prefix is short, terse, and doesn't bloat up the code with "TypeThis" or "TypeThat" or "ThisType" or "ThatType

However, this is not a go convention..I'm just mentioning it because other languages have had these same debates and issues, and solved them long ago. (or rather created a subjective flamewar of who prefers what).

I find this sort of stuff confusing:

    var Name Name

That indeed is confusing, i.e. it would create a variable with the same name as type.

In struct definitions it's less of a problem, because the "Name" will be properly scoped and there is no shadowing.

 

Compared to:

    var Name TName 

The "T" terse letter makes you know for sure what is the type and what isn't, as doubling up on name name or age age can look weird, confusing, and you may mix up what is the type and what is the variable if you are used to reading C..

    var Name Ooops

How do you know if Ooops is the type, or Name is the type?  If you are used to reading C code, you could accidently read it as the type being Name since in C code the type comes first.. not the variable...

People come from different backgrounds, i.e. Delphi programmer would be used to this and not the C syntax.

[fatdo...@gmail.com]

the keyword 'type' is the artifact of a poorly designed lexer/parser.

[chris dollin]

explain why?

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Charles Haynes]

On Wed, Sep 23, 2015 at 1:01 AM, 'chris dollin' via golang-nuts <golan...@googlegroups.com> wrote:

explain why?

In Go there's no ambiguity about when an identifier is a type, and when it's the name of a variable. Not only in terms of the language design itself, but in terms of the cognitive load on the person reading the code. So adding a "Type" to type names is superfluous. Unlike some other languages where type names may be obvious to a compiler, but not to a human, in Go the fact that an identifier is a type name is clear. So decorating identifiers with "Type" adds verbosity without increasing clarity (except perhaps to reassure programmers who are coming to Go from languages where the distinction is less clear.)

Rob's point is that "terseness" in identifiers is a community convention, so in general shorter names are preferred as long as their meaning is clear in context.

This mail message violates that convention, in that Rob's reply contained the same information but more concisely. However you may have to already understand the convention in order to really get that.

-- Charles