From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4FSZHRYYGWF9YwAAWB0awg (envelope-from ) for ; Sun, 15 Aug 2021 09:35:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 76D831EDFB; Sun, 15 Aug 2021 09:35:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 23A891EA7E for ; Sun, 15 Aug 2021 09:35:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A903D3897068 for ; Sun, 15 Aug 2021 13:35:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A903D3897068 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629034517; bh=roHQRn26LNG0zUD3ECUySANrOo2CfrmGd+KluWtzBVk=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=lEz8w9EO7bxv0sUyccqEYKZD61NiC8MCCB9j/T3+q/mEtwxuSGNYjFliqubOqIyHV Oys/czwLQDTGh7XVtIWzjIwqxJsbRybmwGQPC1WJf8/3avYJtdNA0mhX89A7yeXrFT vQXMLHRms6Xll+yVfYxZkgvZ8PI0J+1nTV3l0Spc= Received: from lndn.lancelotsix.com (vps-42846194.vps.ovh.net [IPv6:2001:41d0:801:2000::2400]) by sourceware.org (Postfix) with ESMTPS id 8FCC73857C67 for ; Sun, 15 Aug 2021 13:34:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8FCC73857C67 Received: from lsix-M11x-R2 (unknown [IPv6:2a01:e34:ef9a:d0b0:2bc0:2173:dba3:b87b]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 26EA980D7A; Sun, 15 Aug 2021 13:34:47 +0000 (UTC) Date: Sun, 15 Aug 2021 14:34:43 +0100 To: Simon Marchi Subject: Re: Coding standards proposal, usage of "this" Message-ID: <20210815133443.we6z3tfciud2jdev@lsix-M11x-R2> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (lndn.lancelotsix.com [0.0.0.0]); Sun, 15 Aug 2021 13:34:47 +0000 (UTC) X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Lancelot SIX via Gdb-patches Reply-To: Lancelot SIX Cc: Simon Marchi via Gdb-patches Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Fri, Aug 13, 2021 at 10:26:48AM -0400, Simon Marchi via Gdb-patches wrote: > Hi all, > > Here's something I had in mind for a while. We don't consistently use > `this` when referring to fields or methods of the current object. I > never now if I should use it or not, or point it out in review. I > therefore propose these rules so that we have something to refer to. > > - Use `this` when referring to a data member that is not prefixed by > `m_`. Rationale: without `this`, it's not clear that you are > referring to a member of the current class, versus a local or global > variable. > - Don't use `this` when referring to a data member that is prefixed by > `m_`. Rationale: the prefix already makes it clear that you are > referring to a member of the current class, so adding `this` would > just add noise. > - Use `this` when referring to a method of the current class. > Rationale: without `this, it's not clear that you are referring to a > method of the current class, versus a free function. > > If we had a convention for how to name internal helper methods, which > would make it clear that they are methods of the current object and not > free functions (a bit like `m_` does for data members), we could omit > `this` when calling such a method. But we don't have that at the > moment. > Hi, I think I tend to use both ('this->' and 'm_' prefix) because the 'm_' prefix is used and I have some python habit of using 'self'. I am absolutely fine with your approach to use exactly one of those two markers since both says that they are referring to a member of the class, and having both is redundant. Also, having a rule is a good thing, so count me in. Extending the same sort of convention to helper methods is also reasonable. I do not have an opinion on what should be the prefix. However, classes and structs will more likely have both public (without prefix) and protected/private (with prefix) methods, which can lead to a somewhat less uniform style when writing methods body. I tend to think that for this reason just using 'this->' all the time might be easier, but this is not a strong opinion, I am fine using a prefix. On the other hand, having a prefix can be a nice hint when refactoring code that a given method is not part of the public API and therefore easier to change. Lancelot.