2

I have a function in my program that generates random strings.

func randString(s []rune, l int) string

s is a slice of runes containing the possible characters in the string. I pass in a rune slice of both capital and lowercase alphabetic characters. l determines the length of the string. This works great. But I also need to generate random hex strings for html color codes.

It seems all sources say that it's good programming practice to reuse code. So I made another []rune that held [1-9a-f] and feed that into randString. That was before I realized that the stdlib already inclues formatting verbs for int types that suit me perfectly.

In practice, is it better to reuse my randString function or code a separate (more efficient) function? I would generate a single random int and Sprintf it rather than having to loop and generate 6 random ints which randString does.

borring
  • 69
  • 7
  • You should probably ask this at http://programmers.stackexchange.com/ because your question is entirely subjective. Besides that it's not really that wonderfully worded, why not just modify `randString`? – evanmcdonnal Aug 03 '15 at 20:50
  • 1
    @evanmcdonnal: "Subjectivity" is not a specific criteria for topicality at programmers, except insofar as too much of it makes questions off-topic, just like it does here. – Robert Harvey Aug 03 '15 at 20:52
  • @RobertHarvey I thought programmers was for questions regarding design/best practices/coding style/ect? – evanmcdonnal Aug 03 '15 at 20:58
  • 1
    @evanmcdonnal: That's not what you said. You said that the question should be asked at Programmers because it's entirely subjective. – Robert Harvey Aug 03 '15 at 21:03
  • @RobertHarvey haha pardon my language, I just consider all of those topics to be inherently subjective. Of course there is popular opinion but I see it as nothing more than that. – evanmcdonnal Aug 03 '15 at 21:11
  • It can be tempting to sweat "efficiency" when it's not really an issue. There can't be more than microseconds' difference between the options you're discussing; there may be *no* difference. – twotwotwo Aug 04 '15 at 04:17
  • As a side note: this question is exactly about the function you're trying to create: [How to generate a random string of a fixed length in golang?](http://stackoverflow.com/questions/22892120/how-to-generate-a-random-string-of-a-fixed-length-in-golang) I've presented mutiple very efficient solutions. – icza Aug 08 '15 at 06:39

2 Answers2

3

1) If there is an exact solution in the standard library, you should like always choose to use that.

Because:

  • The standard library is tested. So it does what it says (or what we expect it to do). Even if there is a bug in it, it will be discovered (by you or by others) and will get fixed without your work/effort.
  • The standard library is written as idiomatic Go. Chances are it's faster even if it does a little more than what you need compared to the solution you could write.
  • The standard library is (or may) improve by time. Your program may get faster just because an implementation was improved in a new Go release without any effort from your part.
  • The solution is presented (which means it's ready and requires no time from you).
  • The standard library is well and widely known, so your code will be easier to understand by others and by you later on.
  • If you're already imported the package (or will in the near future), this means zero or minimal overhead as libraries are statically linked, so the function you need is already linked to your program (to the compiled executable binary).

2) If there is a solution provided by the standard library but it is a general solution to similar problems and/or offers more than what you need:

  • That means it's more likely not the optimal solution for you, as it may use more memory and/or work more slowly as your solution could be.
  • You need to decide if you're willing to sacrifice that little performance loss for the gains listed above. This also depends how and how many times you need to use it (e.g. if it's a one-time, it shouldn't matter, if it's in an endless loop called very frequently, it should be examined carefully).

3) And at the other end: you should avoid using a solution provided by the standard library if it wasn't designed to solve your problem...

  • If it just happens that its "side-effect" solves your problem: Even if the current implementation would be acceptable, if it was designed for something else, future improvements to it could render your usage of it completely useless or could even break it.
  • Not to mention it would confuse other developers trying to read, improve or use your code (you included, after a certain amount of time).

As a side note: this question is exactly about the function you're trying to create: How to generate a random string of a fixed length in golang? I've presented mutiple very efficient solutions.

Community
  • 1
  • 1
icza
  • 389,944
  • 63
  • 907
  • 827
  • 3
    To your first section you could add improved readability for other Gophers (i.e. Go programmers know what `fmt.Sprintf("#%06x", rand.Intn(256*256*256))` does and how it works but I'd have to guess at what `"#' + randString(hexRunes, 6)` does and read the code to find out how). – Dave C Aug 03 '15 at 21:45
1

This is fairly subjective and not go-specific but I think you shouldn't reuse code just for the sake of reuse. The more code you reuse the more dependencies you create between different parts of your app and as result it becomes more difficult to maintain and modify. Easy to understand and modify code is much more important especially if you work in a team.

For your particular example I would do the following.

If a random color is generated only once in your package/application then using fmt.Sprintf("#%06x", rand.Intn(256*256*256)) is perfectly fine (as suggested by Dave C).

If random colors are generated in multiple places I would create function func randColor() string and call it. Note that now you can optimize randColor implementation however you like without changing the rest of the code. For example you could have implemented randColor using randString initially and then switched to a more efficient implementation later.

kostya
  • 9,221
  • 1
  • 29
  • 36