From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B077C424CB; Tue, 11 Jun 2024 17:50:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 39F8B40299; Tue, 11 Jun 2024 17:50:59 +0200 (CEST) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id 8DFE04021F for ; Tue, 11 Jun 2024 17:50:58 +0200 (CEST) Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1f7028196f2so20039305ad.2 for ; Tue, 11 Jun 2024 08:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1718121057; x=1718725857; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=t3NeCflcJ79XAK8/MyXhcA66Vv6PFedONPjLLRRhumA=; b=OT0fZulXXGWDxMGHj+MXvtRq7iAEGbBEO11bAfxQChpf7Vetoj4SEjGCEJGPJRhLEf 2cmioDvTdyhB57VhaEjAUsqwwck0PO9BBpa1WoNk6ZVIHXZv7/joAUZLbO4m0T3EFG+n s7qDnzvhSwq0XzqBNwQql9krCS99TwAE+tH1ug7JKeoGzdAnnoG/RRquu9jzIWOT/hC0 Eyfo429x+VxM06w4l9DfYb1Lv1t2tKqDyrPjOp7eH2OCHVjmvzMkTMdIxtvl0IC5ztj0 oTT7XP0gZVf/fBSn6COlt97YGLt4qXyfVRJM+Z/61YwScub/OXyLthh05CdLA8uE+bAk +Peg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718121057; x=1718725857; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=t3NeCflcJ79XAK8/MyXhcA66Vv6PFedONPjLLRRhumA=; b=eMIhYUd9c/CFKZQwWLoPn9mKYwvktewpFFzp9iurxNB5GsWH/OuBfVwxDwNK95wDCy krsUTQ17boxom0FQbcZR24UCW1FXAeUBYq0t7iToxX1K33cYs/KR8sV59RI5ss1BQLIA TKqN6mqPNvcL2RCpph00K5QjZmIQD+rTImugWGLDqfI+9+DTknm5w5xnaL4dWJhbVBT5 UiqiErd/uXP5z9Ds5CGpl9a7uQ/yV/vajQH17WZfHpNUN1xsN8wrfKGdTgoHedQsn9Da DBx+x0oesnA2xiNqlhmJk3M6eVgIyFdt7KQblpqw4fqYD3WgTJeWhF4hSl+f2VXA5pV4 4fxA== X-Forwarded-Encrypted: i=1; AJvYcCXcXBLTrlJ6S89kUZbF26o7d34ybcMnCfxjBaMvn/hQqqA9Jl75SxWsYePiswbS9nEJTiB2dylz1ZnPeJU= X-Gm-Message-State: AOJu0YzZ5KCFyVpCVmFnRn4tbqBUevK7ZWiz6PxFZgY/z9il5L5InfrD aUvjhA0mRhjvfMFgjMdbpE3v7M/kgDxVZRzPUDjQtTUt2WdvxjbePj8JQ7sJhCc= X-Google-Smtp-Source: AGHT+IFqrW3ySecTw7u6wG8L8IsAr/P4hWsqvwdG29mdSlE2DLGaSZi9ADqLWncXrFAyFco1wJ2CNA== X-Received: by 2002:a17:902:f685:b0:1f7:12f3:b975 with SMTP id d9443c01a7336-1f712f3bb07mr69340225ad.43.1718121057324; Tue, 11 Jun 2024 08:50:57 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f6f2c825e9sm63471805ad.291.2024.06.11.08.50.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 08:50:57 -0700 (PDT) Date: Tue, 11 Jun 2024 08:50:55 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , dev@dpdk.org Subject: Re: Coding Style for local variables Message-ID: <20240611085055.373980e4@hermes.local> In-Reply-To: <190c4772-9ee5-466a-adc1-a0c4f5bb75f8@amd.com> References: <98CBD80474FA8B44BF855DF32C47DC35E9F512@smartserver.smartshare.dk> <190c4772-9ee5-466a-adc1-a0c4f5bb75f8@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 11 Jun 2024 16:10:33 +0100 Ferruh Yigit wrote: > On 6/10/2024 4:10 PM, Morten Br=C3=B8rup wrote: > > The coding style guide says: > >=20 > > "Variables should be declared at the start of a block of code rather th= an in the middle. The exception to this is when the variable is const in wh= ich case the declaration must be at the point of first use/assignment. Decl= aring variable inside a for loop is OK." > >=20 > > Since DPDK switched to C11, variables can be declared where they are us= ed, which reduces the risk of using effectively uninitialized variables. "E= ffectively uninitialized" means initialized to 0 or NULL where declared, to= silence any compiler warnings about the use of uninitialized variables. > >=20 > > Can we please agree to remove the recommendation/requirement to declare= variables at the start of a block of code? > > =20 >=20 > My concern is it may break the consistency in the code. > If there is an existing function that defines N variables at the > beginning of the function, new feature defines a new variable close the > the feature block, this inconsistency bothers me more than all variables > being defined at top. There are few places where putting declarations in middle makes sense, like for (int i =3D 0; i < 10; i++) >=20 > Variables being defined on top only bothers me when function is too big > and I can't see the variable declaration at the same time while I am > reading the code. Then the function is too big to start with! > If functions is small enough to fit ~50% of my screen, locations doesn't > really matter, I can still observe (effectively) uninitialized variables > etc... > Instead of trying to optimize big functions, I am for doing other way > around to encourage smaller functions. Agreed > (Indeed I prefer 80 column limit with 8 space indentation for exact same > reason, this *artificial* limit only allows some number of indentation > and at some point forces developer to extract some part of code as new a > function.)