Suggestion: unused variables and packages

[Starfish]

Hello!

When unused packages or variables are present in Go code, the compiler gives error.

Suggestion: make it possible to delete unused variables with the compiler or maybe the gofmt tool.

[Jesse McNelis]

On Fri, May 3, 2013 at 10:42 PM, Starfish <ahn...@rocketmail.com> wrote:

When unused packages or variables are present in Go code, the compiler gives error. 

Suggestion: make it possible to delete unused variables with the compiler or maybe the gofmt tool

The error isn't there just to annoy you. It's there to help you find bugs in your code.

A unused variable or import can often be hiding a bug where a variable or package name has been incorrectly shadowed.

If gofmt automatically removed these it would be hiding these bugs from you.

[Péter Szilágyi]

Hi!

  Automatically deleting unused imports could I guess be doable, but is it really that hard to delete a line? :P Most editors already have shortcuts to remove an import.

  Removing unused variables on the other hand is imho, a bad idea. It usually means I forgot about something and I'd much rather the compiler warn me and not try to further hide a possible bug. I think the case of unused variables is much too complex for the compiler/gofmt/whatever to make any sort of intelligent decision.

Cheers,

  Peter

--
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.
 
 

[chris dollin]

On 3 May 2013 13:42, Starfish <ahn...@rocketmail.com> wrote:

When unused packages or variables are present in Go code, the compiler gives error.

Yes.

 

Suggestion: make it possible to delete unused variables with the compiler or maybe the gofmt tool.

What's wrong with using the editor that must just have been used
to create the unused items?  That gives you the opportunity to make

the right choice -- something neither the compiler nor gofmt is likely

to be able to do.

Chris

--
Chris "allusive" Dollin

[Péter Szilágyi]

I think the problem with having such a flag is that people would abuse it (i.e. add it as a standard compilation flag always), which would in effect defeat the purpose of the warnings. It would become similar to gcc warn levels where instead of forcing a dev to write always write good code, it would become a post-processing step. Yes, I agree that commenting a block can sometimes be annoying, but it's very rare in a bigger code base (something else will use the same import anyway), and having the extra check can be a life saver.

On Fri, May 3, 2013 at 2:57 PM, Frans Eliasson <frel...@gmail.com> wrote:

The thing is, one very often comment out sections of code temporarily, but then the compiler complains and one has to comment out even more. 

Perhaps the feature I'm really looking for is a way to run the code regardless of unused variables, using some flag.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/BWDmZFX9hRI/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Jan Mercl]

On Fri, May 3, 2013 at 2:42 PM, Starfish <ahn...@rocketmail.com> wrote:

It's feasible and probably a nice exercise to do. However, this error
becomes more and more rare with experiences and even then - it's
usually like one or max two variables in the code which was freshly
hacked; so the remedy takes less seconds manually than to invoke a
tool, I guess.

-j

[Daniel Jo]

More useful, I think, would be an IDE feature that could automatically mark unused variables and imports as one writes code. Add a command to comment or delete this variables or imports or just do it manually.
-Daniel

--

[Andrew Gerrand]

On 3 May 2013 10:13, <itmi...@gmail.com> wrote:

On Friday, May 3, 2013 4:35:19 PM UTC+3, Ostsol wrote:

More useful, I think, would be an IDE feature that could automatically mark unused variables and imports as one writes code. Add a command to comment or delete this variables or imports or just do it manually.
-Daniel

Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?

No.

 

Go, as a language, is just another tool in the shed, another hammer. However hard it may try, it will never ever be a substitute for real logic and understanding when it comes to opting.

I don't think Go tries to be a substitute for real logic and understanding. 

My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.

Your opinion is at odds with the language design goals.

http://talks.golang.org/2012/splash.article

If you want suggestions about potential errors in your code, use go vet.

Andrew

[chris dollin]

On 3 May 2013 15:13, <itmi...@gmail.com> wrote:

On Friday, May 3, 2013 4:35:19 PM UTC+3, Ostsol wrote:

More useful, I think, would be an IDE feature that could automatically mark unused variables and imports as one writes code. Add a command to comment or delete this variables or imports or just do it manually.
-Daniel

Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?

You are in control; you can take the errors out of your code. That you
don't think an unused variable or package is an error is an opinion

not shared by the language designers (and at least one language user).

 

Go, as a language, is just another tool in the shed, another hammer. However hard it may try, it will never ever be a substitute for real logic and understanding when it comes to opting.

I don't think anyone has claimed otherwise.

 

My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.

Aren't those what `go vet` is for? Horses for courses and all that.

[Andrew Gerrand]

On 3 May 2013 10:28, <itmi...@gmail.com> wrote:

On Friday, May 3, 2013 5:16:37 PM UTC+3, Andrew Gerrand wrote:

Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?

No.

Enlightenment comes in many shapes or forms. "No" is not it.

If I thought you had any interest in enlightenment I would expend more effort.

  

My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.

Your opinion is at odds with the language design goals.

http://talks.golang.org/2012/splash.article

I think I've addressed this one: mold the goals once the language gets in the hands of users. It appears that field testing, sort of speak, goes against the initial concepts baked in a laboratory. If you want Go up then you need to GrOw up.

I have travelled the world and met hundreds of Go programmers. Most have said that they actually appreciate the "no warnings", "no unused variables", and "no unused imports" rules, even if it was hard to get used to at first. You are in the minority.

If we try to satisfy everyone we will end up with C++. Design by committee is ineffective at best and dangerous at worst.

Your tastes and desires are clearly at odds with the project's goals. If Go is not the language for you, please use something else!

Andrew

 

[Aaron France]

Go is opinionated. I like that. Go makes certain choices. I like that. That is the enlightened thing about Go, it makes choices where other languages are afraid to do so. It doesn't always get them right but it's better than trying to please everyone.

[Andrew Gerrand]

On 3 May 2013 11:05, <itmi...@gmail.com> wrote:

Every single time it comes to this: "we know better, here's the door".

Unpleasant, to say the least. And very immature. 

You're not giving me many other options. Unless you think I should say "Oh, of course Dumitru! You have convinced us all to change our minds and do things the way you would like!" I'm sorry that we disagree, but it seems we are at an impasse.

 

Let me ask you this: you think that every honest request is out to get Go and ruin it?

No. Many honest requests have become significant changes to the language, libraries, and tools. But in this case, we have provided our rationale and you do not accept it.

Clearly we have fundamentally different ideas about how languages should be built. And that is fine; Go is not the only language in the world. But, that being the case, it would seem you are wasting your time here.

Andrew

[Jeremy Wall]

On Fri, May 3, 2013 at 9:28 AM, <itmi...@gmail.com> wrote:

On Friday, May 3, 2013 5:16:37 PM UTC+3, Andrew Gerrand wrote:

Don't you think it would be best if neither the compiler nor a random IDE would have the control, but instead I would be in control of that?

No.

Enlightenment comes in many shapes or forms. "No" is not it.

 

Go, as a language, is just another tool in the shed, another hammer. However hard it may try, it will never ever be a substitute for real logic and understanding when it comes to opting.

I don't think Go tries to be a substitute for real logic and understanding. 

Yes it does, when it decided to stop my code it doesn't really understand, based on random and bias observations of it.
 

My opinion that Go should in fact have lots and lots of warnings: about shadowing, about channels, about interfaces, about structs. A lot of issues are left unnoticed while this uninteresting and dumb one is kept on only as a statement, not as a real proven benefit.

Your opinion is at odds with the language design goals.

http://talks.golang.org/2012/splash.article

I think I've addressed this one: mold the goals once the language gets in the hands of users. It appears that field testing, sort of speak, goes against the initial concepts baked in a laboratory. If you want Go up then you need to GrOw up.

This particular goal arises from field testing the converse behaviour in other languages and finding it to be a hindrance to long term maintenance and large scale development. There are lots of languages that have warnings about unused variables. Go will *probably* never have that behavior. If it's that much of a pain then use a language that has the feature. Otherwise just drop it. It's not a battle worth fighting because it's not a battle you'll win.

 

 

If you want suggestions about potential errors in your code, use go vet.

Andrew

As the original poster of this possible solution, you don't have to mention this option to me.

--
Mitică

[DisposaBoy]

Hold on guys. Let me grab a chair

[Aaron France]

http://i.imgur.com/FaM7K7j.gif

On Fri, May 3, 2013 at 6:46 PM, DisposaBoy <dispo...@dby.me> wrote:

Hold on guys. Let me grab a chair

[Andrew Gerrand]

On 3 May 2013 12:25, <itmi...@gmail.com> wrote:

That is real stupid argumentation against a very simple and clear request.
You really need a shift in mentality, before anything.

I'm sure it will happen eventually, it's just mind boggling how egotistical the language issues have become in the eyes of the language designers at the expanse of the general audience.

Rather than even admit the remote possibility that there might be actual rational reasons for this design decision, you instead conclude that it is the hubris of the Go developers that prevents the language from being changed to the suit your preferences. The irony here is astounding.

Well, I have had enough. You do not contribute anything of value, only insults and negativity. We, the contributors who have invested so much of our time and energy into making Go great, do not deserve this kind of treatment.

I must now request that you stop posting to this mailing list.

Sincerely,

Andrew

[Hotei]

The unused import/variable thing is at worst a "nuisance" that for this year so far has consumed about 15 minutes of my time to appease the compiler.  On the plus side - in the same 4 months it caught me in a lot of glaring oops but also a few dozen more subtle errors (shadows mostly) that had the program compiled without error would have taken me hours to find and fix.  Life is a series of trade-offs and so far the go designers have done a better job of making those trade-offs than any other language that I'm aware of.  YMMV.

[Tad Glines]

I too have been occasionally annoyed with the "no unused imports/variables" feature. However, I consider it a fair trade for what I get in return. Besides being a security concern, dead code also poses a maintainability issue. When code contains unused variables or functions, it makes it more difficult to understand the code. I've had to work with code bases that where littered with unused bits of previous iterations of the code. It makes maintaining the code more difficult and error prone.

I'd actually welcome being forced to remove unused functions as well. In this case it would really only work with private functions, but still it would force the developer to comment out any unused functions and eliminate the need to answer the question "what's this used for?". Or maybe a comment code (like the build flags) could be added so that a function must be flagged as unused if it isn't referenced by any other code in the package (including the tests). And, if the function is only used in tests then it should be required to be in a "_test.go" file.

--

[Jan Mercl]

On Fri, May 3, 2013 at 9:46 PM, Tony Fandali <tfan...@gmail.com> wrote:

Alias cc redundant.

-j

[Steve McCoy]

On Friday, May 3, 2013 3:46:33 PM UTC-4, Tony Fandali wrote:

There is also a certain irony that follows due to this, "we created a language that C++ people should like, but they don't like it! But they must, we did all the "right" things! " 

Nobody said that people must accept Go's way of doing things, or that they are objectively the right way. Andrew even said the opposite: If you don't like a Go feature such as the subject of this thread, you are free to use a different language or environment. You are even free to use a 3rd party tool like gosloppy to work around what you don't like. This is not him being mean, this is simply pointing out that people are free to use what they actually like — things that exist — rather than contorting Go.

It is not condescending or egotistical to say "no" to requests that contradict the goals of a project.

[Hotei]

At one time I would have suggested github.com/remyoudompheng/go-misc/deadcode but it looks like it's not hosted there anymore.  Perhaps the author can help?  I have a version from about a year ago and it works well for me.

[Andrew Gerrand]

I agree there are certainly people in this group who could be nicer, but I would describe them as pedantic rather than condescending. Indeed, if you look through the archives of this group you can find hundreds of threads where someone has asked for help and received dozens of helpful, factual responses. Numerous times I have seen people outside this group comment on how helpful the people here are.

However, if you come to the group to declare you know a better way of doing things, especially if you do not even write real Go code, then you should expect a chilly response. If you are not at all invested in the project, yet expect your opinions of language design to be respected like those who have invested years working on Go, then you're going to have a bad time.

It should also be said that it is much easier to quibble over minor aspects of language design than to do the hard work that actually improves the Go ecosystem. I am personally chagrined to have spent so much of today contributing to this thread, when I should have been writing code.

Rust is in a different stage to Go: they're still working on the core language, and aren't that close to 1.0. It is natural that they should be more receptive to language design suggestions. I don't know much about the Scala community, but their design philosophy is certainly more inclusive than that of Go.

As has been said elsewhere, Go is an opinionated language. To stay that way it needs to have opinionated maintainers. I personally view that as a virtue, but some people have different ideas and have their feelings hurt when Go's ethos disagrees with them.

There is very little I can do but reiterate our goals, and encourage those with different goals to find another community of people that share their ideas.

Andrew

--

[Brendan Tracey]

There is also a certain irony that follows due to this, "we created a language that C++ people should like, but they don't like it! But they must, we did all the "right" things! " The language does seem to be attracting a lot of Python/Ruby/etc programmers though, which in retrospect is not really surprising. It seems that Go is becoming another web dev language.

There are also a number of us who are using Go as a language for scientific computing. The tools are not yet in place yet for me to become a full evangelist for it, but I'm hopeful for its future as such.

[Hotei]

Sorry for the confusion Remy,

After a search I found in this repo https://github.com/remyoudompheng/go-misc

[Michael Jones]

On Sat, May 4, 2013 at 2:51 AM, suharik <gleb....@gmail.com> wrote:

Why don't just add a flag that makes compiler ignore unused packages and variables error? That can be useful for testing incomplete code.

For the same reason that Mitică's being told no -- it has been shown conclusively to have a fundamental problem in large-scale (big team) software development. In any big team, there will be people not as careful as others and not as detail-oriented as others. Those people will leave dead code in their work and use lax modes in their build infrastructure. It will creep into the larger effort, and begin accruing technical debt from that moment forward. If you have ever worked with a large body of code then you know that this happens.

One of the foremost goals of Go is to build a simple language that structurally prevents as many classes of larger-scale software engineering problems as possible. If you go through a checklist of major problems encountered by big teams, you'll see things like unused variables, misunderstood type conversions, unchecked return values, error values taken as real data, dynamic allocations used after free(), problems with asynchronous code, and so on. Compare any such list with Go's features and you'll see that the true authors of Go are the historic troublemakers on large software teams.

The Go team is realistic that this new level of "safe coding" may be 1% less convenient for some people, in some circumstances, especially when writing a simple "toy" project. Also realize that the Go authors may themselves be inconvenienced in such cases. This is not some blindness to the issue Mitică raised, it is a studied commitment to solve a serious issue in software engineering.

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Kosztka Imre Dávid]

+1

2013/5/4 Michael Jones <m...@google.com>

--

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.
 
 

--
Name : Kosztka Imre Dávid
E-mail: kosz...@gmail.com
Phone number: +36309213462
Mailing address: H-3700, Hungary Kazincbarcika Szeder utca 2.

[Peter]

Not to mention the features that prevent buffer overflows, stack overflows, undefined behaviour of integer overflow, unicode-blindness, unchecked error codes. Or a standard library that helps prevent injection attacks (html/template), malicious worst-case attacks (sort, built-in map, regexp), roll-your-own crypto, leap-year confusion.

It's like someone literally went through the CERT C book and CVE database and said "how could Go help with that"? Ken?

[andrey mirtchovski]

Peter's comments lead me to believe that Michael's post, slightly
expanded, will make a great propaganda piece for go.