The current sorting is done by type of expression and then by size of the "construct". It seems this is done before the naming unification because it can decrease the quality of the representation. For bird watcher, the order of functions/tasks is different from representation to representation although it is the same in the solution code. That reduces the likelihood that two solutions have the same representations.

Commenting out the sorting let to somewhat better results (no massive improvement though). In general, the sorting is a good thing though but it seems we should fine tune the logic so that it keeps the order of the tasks. That also makes it easier to reconcile the representation with the student code when looking at it.

This issue is to collect ideas for additional normalizations that the representer could make so that more student solutions would get a matching representer comment in the future.

Some things to keep in mind:

• The admins currently tend towards the idea that it would be ok if the analyzer would comment on something and the representer would then normalize the same thing. So just because something is listed below does not mean the student would not get feedback on it.
• The mentor that writes a representer comment would see a list of normalizations that are potentially applied and should therefore not be commented on.
• Some normalizations might not be worth the effort coding them as they will not significantly decrease the number of unique/rare representations. It is a bit hard to tell which ones those are exactly and where to draw the line so it is ok to collect all ideas for now.

The normalizations that are currently applied can be found in the README.

Ideas for additional normalizations:

• variable declarations, e.g. var a string vs. a := ""
• variable increment, i++ vs. i = i + 1 vs. i += 1
• make without capacity and length vs. non make version (slices/maps)
• new(someStruct) vs. &someStruct{}
• unnecessary variable declaration before return

  x := someFunction()
  return x
  

• Single import with and without brackets

  import "fmt"
  // vs.
  import (
      "fmt"
  )
  

• Named return values but the names are unused

  func myFunc() (y int) {
     return calc()
  }
  

• Remove example tests that a student might have written
• len(someString) == 0 vs. someString == ""
• expressions where the order does not matter, e.g. simple math expressions like return 2*x vs. return x*2
• constants with unnecessary type definition, e.g. const x int = 40 vs. const x = 40 (not sure it is possible to know when this normalization is ok to do though)
• slice[0:n] vs. slice[:n]
• > x-1 vs. >= x when x is int/uint

(Some items on the list are taken over from #10. Note that some others listed there were already implemented. Other items on the list are from looking at distinctions that appear between the current representations.)

If you have additional ideas or are interested in implementing one of the normalizations, please leave a comment below.

I would like to work on the representer for GoLang https://github.com/exercism/go-representer

If this is already being worked on, feel free to close this issue.

Design thoughts:

• remove comments
• change variables to standardize the naming
• use go fmt

I am still new to Exercism development, so some help on the framework would be appreciated.

I also think https://staticcheck.io/ could be useful for automated suggestions or as a tool for mentors when reviewing the "common" cases.

In line with our new org-wide policy, the master branch of this repo will be renamed to main. All open PRs will be automatically repointed.

GitHub will show you a notification about this when you look at this repo after renaming:

In case it doesn't, this is the command it suggests:

git branch -m master main
git fetch origin
git branch -u origin/main main

You may like to update the primary branch on your forks too, which you can do under Settings->Branches and clicking the pencil icon on the right-hand-side under Default Branch:

We will post a comment below when this is done. We expect it to happen within the next 12 hours.

When I publish the following code:

// Package twofer allows on to generate a sharing message.
package twofer

import "fmt"

// ShareWith takes a name and returns a sharing greeting.
func ShareWith(name string) string {
	if name == "" {
		name = "you"
	}

	return fmt.Sprintf("One for %s, one for me.", name)
} 

there is an error creating a representation for it:

2023/09/21 12:17:55 Creating representation for `two-fer` exercise in folder `/mnt/exercism-iteration/`
2023/09/21 12:17:56 /mnt/exercism-iteration/two_fer.go:4:8: could not import fmt (can't find import: "fmt")
github.com/exercism/go-representer/representation.(*Representation).parseInfo
        /go-representer/representation/representation.go:90
github.com/exercism/go-representer/representation.(*Representation).ParseAST
        /go-representer/representation/representation.go:67
github.com/exercism/go-representer.Extract
        /go-representer/representer.go:13
main.run
        /go-representer/cmd/representer/main.go:60
main.main
        /go-representer/cmd/representer/main.go:50
runtime.main
        /usr/local/go/src/runtime/proc.go:250
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1598
failed to parse solution AST

Go 1.18 is a very anticipated release of the language due to the inclusion of generics, among other things. We should update the tooling of the Go track to support solutions using Go 1.18.

• Go 1.18 release notes

This update should be similar to the upgrade done for 1.17:

• #12

Tracking issue: exercism/go#2129

When we want to take our representer online and have mentors write representer comments, we need to have this kind of documentation in the track repo: https://github.com/exercism/fsharp/pull/1092/files

(I am keeping the issue here because the "source" for those what's documented is in this repo.)

After the new docs were added, they should be linked in the readme of this repo. The current list of normalizations can then be removed.

I had a look at the current state and noticed a couple of minor things we might want to address:

• Currently there is no test case that covers the multiple files case
• Is there any reason we call the file with the test fixtures tests and not testdata which is the official name?
• Would be good to have a .gitignore file that contains vendor in case someone runs in vendored mode, the represent executable that is created when running the command from the readme and any .exe files that are created on Windows
• Would be good if the readme also showed an example command that would actually run, I found this very helpful with the testrunner, e.g. ./represent hamming ./representer/tests/hamming/1 . (not sure how it looks for windows)

cc @tehsphinx