Hey, my name is Austin and i had a suggestion about lasagna/go exercise. I already cloned the repository, created a branch and commit two changes. Do i need collaborator access to push my branch to make the PR right? Can i have it?
Prior to making any PRs, you should start a discussion about what you believe can be improved and whether or not the track maintainers would like contributions at this time. Most tracks have community contributions paused (see this announcements) and PRs which are not pre-approved are automatically closed.
1 Like
In addition to what @IsaacG says, you should also use your own Fork when making pull requests. You won’t be able to push the main repository.
But please have a chat here about your ideas as the first port of call 
1 Like
Good night guys, sure and thanks for replying. My suggestions for the lasagna exercise(go/2) are:
- Add another constant, in the exercise it is asked to declare the constant “OvenTime” but I think that “PreparationTimePerLayer” should also be added to make the code easier to understand by avoiding the “magic” number 2 in the “PreparationTime” function.
- Change the data type int to uint8, due to the context provided in the exercise, only values within the range of uint8(0 to 255) will be used, so I think it is a good practice to save memory, taking into account that Go is characterized by efficiency. We can also comment on the other types of numerical data that are not so well known.
I would like to know your feedback on the ideas.
Using a constant for that value 2 is a good idea. The exercise, as it currently is written, does not prevent you from doing so. The exercise requires one constant be defined, which “teaches” the concept. Requiring a second constant does not teach any additional material, but adding that in would break all existing solutions. The exercise, as it is currently written, is consistent with how it’s done in Python.
While using a constant there would be good practice, and something I’m sure a mentor would recommend, I’m not sure the pros of changing the exercise outweigh the cons.
Similar to the prior point, a uint8 might be sufficient here, but saving a byte of memory really, really isn’t a big deal. It’s hard to justify breaking all the existing solutions in order to save one byte of memory. Additionally, since registers are typically 32 or 64 bits large, a uint8 can still take the same amount of memory as an int to store and operator on.
Golangbot says,
You should generally be using int to represent integers unless there is a need to use a specific sized integer.
As such, I’m not sure uint8 is actually better.
1 Like