fix: fix slice init length

[wangjingcun]

The intention here should be to initialize a slice with a capacity of len(delegates) rather than initializing the length of this slice.

The online demo: https://go.dev/play/p/q1BcVCmvidW

[p4u]

Actually, since append is used, there is no need for 'make'. We can just define the slice as prettierDelegates := []string{}

[wangjingcun]

Actually, since append is used, there is no need for 'make'. We can just define the slice as prettierDelegates := []string{}

Modified, please review again

[jordipainan]

prettierDelegates := []string{} is still suboptimal.

• Old version:

func printPrettierDelegates(delegates [][]byte) []string {
    prettierDelegates := make([]string, len(delegates))
    for _, delegate := range delegates {
        prettierDelegates = append(prettierDelegates, ethcommon.BytesToAddress(delegate).String())
    }
    ...

This code creates a slice prettierDelegates with a fixed length equal to len(delegates), but then appends to the slice. This results in the slice growing unnecessarily. The pre-allocated slice slots remain unused, so you end up with a slice of twice the intended size, with the first half containing zero-value strings.

• Proposed version:

func printPrettierDelegates(delegates [][]byte) []string {
    prettierDelegates := []string{}
    for _, delegate := range delegates {
        prettierDelegates = append(prettierDelegates, ethcommon.BytesToAddress(delegate).String())
    }
    ...

This version works correctly but doesn't pre-allocate any capacity. For a small number of delegates, this isn't an issue, but if delegates is large, it can cause multiple memory allocations as the slice grows.

• Optimal version:

func printPrettierDelegates(delegates [][]byte) []string {
	prettierDelegates := make([]string, 0, len(delegates)) // Capacity set to length of delegates
	for _, delegate := range delegates {
		prettierDelegates = append(prettierDelegates, ethcommon.BytesToAddress(delegate).String())
	}
...

This version is more efficient while being correct. It avoids unnecessary re-allocations by pre-allocating the right amount of capacity while still using append to add elements in order. You have enough space for all elements, avoiding multiple memory allocations and the slice starts with a length of 0, so append adds elements in order without leaving any zero-value entries.

[wangjingcun]

This version is more efficient while being correct. It avoids unnecessary re-allocations by pre-allocating the right amount of capacity while still using append to add elements in order. You have enough space for all elements, avoiding multiple memory allocations and the slice starts with a length of 0, so append adds elements in order without leaving any zero-value entries.

Has been modified.

In fact, this is the version I first submitted. This can avoid memory overhead caused by multiple expansion, and there is no problem with the previous part of the element zero value.

Thanks for your guidance and please review again.

[coveralls]

Pull Request Test Coverage Report for Build 11720758074

Details

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• 6 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.007%) to 62.202%

---

Files with Coverage Reduction	New Missed Lines	%
util/zk.go	2	86.84%
vochain/state/account.go	2	67.46%
vochain/transaction/election_tx.go	2	62.13%

Totals
Change from base Build 11497416356:	-0.007%
Covered Lines:	16828
Relevant Lines:	27054

---

💛 - Coveralls