From: Alex Young Date: 2012-07-04T17:36:09+09:00 Subject: [ruby-core:46170] Re: [ruby-trunk - Feature #6693][Open] Don't warn for unused variables starting with _ On 04/07/12 05:01, marcandre (Marc-Andre Lafortune) wrote: > > Issue #6693 has been reported by marcandre (Marc-Andre Lafortune). I don't know about anyone else, but I'm already using _foo as a pattern for private-like markers. I think I picked it up from Python. What I mean when I say "private-like" is "you can see this but shouldn't have to touch it", or "I need a visible identifier here which won't collide with your code". It often crops up with delegates or proxies where I need to obviously separate out the methods on the intermediary from the methods on the target. For example: class VCR attr_reader :_calls def initialize( delegate ) @delegate = delegate @_calls = [] end def method_missing(sym, *args, &blk ) @_calls << [sym, args, blk] @delegate.__send__( sym, *args, &blk ) end end Here I don't want the #_calls method to be likely to collide with anything on @delegate, so I'm using a _ as a sort of method_missing-escaping namespace. While this isn't specific to local variables, it would be extremely confusing to have identical-looking conventions for local variables and methods meaning completely different things. Does anyone else do this, or is it just me? -- Alex > > ---------------------------------------- > Feature #6693: Don't warn for unused variables starting with _ > https://bugs.ruby-lang.org/issues/6693 > > Author: marcandre (Marc-Andre Lafortune) > Status: Open > Priority: Low > Assignee: > Category: core > Target version: 2.0.0 > > > Currently, variables which are set but not used will generate a warning (ruby -w), except if they have the special name "_". > > So best practice is to use "_" for all unused variables. This does not encourage readable code. > > # Currently must read: > _, _, _, suffix = parse_name > > # could read: > _first, _middle, _last, suffix = parse_name > > We should not warn for unused variables starting with a "_". > > This would create an option (but no obligation) to use more descriptive names than "_" without generating warnings. > > >