Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC77DC64EC4 for ; Sat, 4 Mar 2023 15:01:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229677AbjCDPBw (ORCPT ); Sat, 4 Mar 2023 10:01:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbjCDPBv (ORCPT ); Sat, 4 Mar 2023 10:01:51 -0500 Received: from ms.lwn.net (ms.lwn.net [IPv6:2600:3c01:e000:3a1::42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFB49CDD0 for ; Sat, 4 Mar 2023 07:01:48 -0800 (PST) Received: from localhost (unknown [IPv6:2601:281:8300:73::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 09DD52D3; Sat, 4 Mar 2023 15:01:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 09DD52D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1677942107; bh=Dy3GMJRCcyJI6flIQ6mIYDtYEv3aWSWcRGCgUowv2Rc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=naRwBbQzG1kwwJ21J40qVZTI8uIci9CRvtvnRtX4kryQ88YsVjkB2ssyHWqhiINDb r40RzJCUH3QABRQb6SCbp3n1wm9QkZXDTDaKwHj/xmwYeIaZGK1uG569JwhmESNw9k V7TyQvCOuZ55Elel3BalijV7IryhfBaJN0H8X/UVIuziEGQO75//+S3TruMQxxHLpp DMPjutwh+N014T9/VP+L9sOtfHZzkd669656xssvcc/Oegqq1XXepF0VRSsN5EATUb h10Jdz2h1S7QWjGErBIULPBDEqQ4DWsr+sy9CdZmnIf3dNYAKQ9aTf1LKb1cxqq7S2 eu+EjFUCYeTcg== From: Jonathan Corbet To: Wei Wang , arnd@arndb.de, akpm@linux-foundation.org, keescook@chromium.org, herbert@gondor.apana.org.au, josh@joshtriplett.org, jani.nikula@intel.com, jgg@mellanox.com, dmatlack@google.com, mizhang@google.com, pbonzini@redhat.com, seanjc@google.com Cc: linux-kernel@vger.kernel.org, Wei Wang Subject: Re: [PATCH v1 2/3] Documentation/CodingStyle: do not use data type names as variable names In-Reply-To: <20230304041932.847133-3-wei.w.wang@intel.com> References: <20230304041932.847133-1-wei.w.wang@intel.com> <20230304041932.847133-3-wei.w.wang@intel.com> Date: Sat, 04 Mar 2023 08:01:46 -0700 Message-ID: <87mt4szhk5.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Wei Wang writes: > Observed some merged code uses "bool" as variable name. This is > confusion either for the reader or compilier. Add a rule to have > programmers avoid using data types as variable names. > > Signed-off-by: Wei Wang > --- > Documentation/process/coding-style.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst > index 007e49ef6cec..6d7f4069d55d 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -356,6 +356,9 @@ specification that mandates those terms. For new specifications > translate specification usage of the terminology to the kernel coding > standard where possible. > > +"bool", "int", "long" etc. are specific names for data types, C > +programmers should not use them as variable names. It seems you found one place where bool was being misused. Fixing it was certainly the right thing to do, but I'm not convinced we need to add clutter to the documentation for this. Thanks, jon