From dev-return-31310-archive-asf-public=cust-asf.ponee.io@geode.apache.org Mon Jun 24 23:28:56 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 1FF0E180671 for ; Tue, 25 Jun 2019 01:28:56 +0200 (CEST) Received: (qmail 77379 invoked by uid 500); 24 Jun 2019 23:28:55 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 77368 invoked by uid 99); 24 Jun 2019 23:28:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Jun 2019 23:28:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id A71801A33CE for ; Mon, 24 Jun 2019 23:28:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id ku8GX8XzXQRs for ; Mon, 24 Jun 2019 23:28:52 +0000 (UTC) Received: from mx0a-00296801.pphosted.com (mx0a-00296801.pphosted.com [148.163.150.38]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id A49A55FDF2 for ; Mon, 24 Jun 2019 23:28:51 +0000 (UTC) Received: from pps.filterd (m0114583.ppops.net [127.0.0.1]) by mx0a-00296801.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5ONQEQZ023214 for ; Mon, 24 Jun 2019 23:28:50 GMT Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by mx0a-00296801.pphosted.com with ESMTP id 2t9b3nss3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 24 Jun 2019 23:28:49 +0000 Received: by mail-pf1-f197.google.com with SMTP id 140so10512606pfa.23 for ; Mon, 24 Jun 2019 16:28:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=VyQMGLugBvOU9r+XyZKKq5pgqq0pETMTYZa25KwDn28=; b=cdD6OPWAJO8wQnB4XwksvJ8p2s0IZhFqlYW8TEh07hgOglW2/GG/dP07w4UtFPIy8y j2H5w5nCH2qlRAu91FlvNhHpRpkw5Pa8y/RpXT1PgrU1/ZneAbamFW/O4pP+D6zB6Y01 BIFw+LVGK+91LNySI+WnGyjDca5bMQoXjAtILpl1LHh22C0qdizrU4ycbdw1Zs0K+2Mv tVrtnmb4qzGLa9qjE81iRMV2vh3L9WWMccHs4rZXQwVPsujQzUZDK/mE9UdR84RHNtiQ 9q8s0rioFfPRW9nZMljFoXiaxx7FYZjQfbdMpjpL4sXEA3YDqShw+zLHG9UJ5++0sjN1 rHFQ== X-Gm-Message-State: APjAAAW5lqwp/vwJ37lz6MlOYQFSXl/pG1ADPOZwP4lvtvTjm7etB6WH tx9pGvtqeKC/D99RrLvmah03xJ/DUXnXn2jjd/1OOjh6yNm10UstOgim4PSGsUmHV4igOLWMM0H 5Ml5YAGXKVgVd56Q9AJvAGU3imZYaVbGw7qp1F4k= X-Received: by 2002:a17:902:23:: with SMTP id 32mr89171278pla.34.1561418928445; Mon, 24 Jun 2019 16:28:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyoYkTJZYMiY2Di38oIXdTm8ngwFpND23GbAIeVbRmE9ykNPJsIINgjeQgQ3fiQbYmLiR2QJg== X-Received: by 2002:a17:902:23:: with SMTP id 32mr89171244pla.34.1561418928025; Mon, 24 Jun 2019 16:28:48 -0700 (PDT) Received: from [10.118.20.33] (50-203-225-134-static.hfc.comcastbusiness.net. [50.203.225.134]) by smtp.gmail.com with ESMTPSA id r15sm14630781pfh.121.2019.06.24.16.28.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 16:28:47 -0700 (PDT) From: Owen Nichols Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [DISCUSS] Adoption of a Coding Standard Date: Mon, 24 Jun 2019 16:28:46 -0700 References: To: dev@geode.apache.org In-Reply-To: Message-Id: <8873A3A9-5A0F-46AB-92E7-DC2B83AE1C57@pivotal.io> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-24_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906240185 I like the idea of a recommended reading list for Geode contributors. My concerns around adopting broad standards and guidelines that can=E2=80=99= t be automatically checked & applied are twofold: a) what is the policy regarding existing code? Is every PR going = forward expected to bring every file it touches into conformance? b) how do we avoid PR reviews devolving into style-nitpicking? If a PR = clearly fixes a bug, but someone doesn=E2=80=99t like a variable name, = would that be reason to give it a -1? Even better would be leading by example [if we can=E2=80=99t overhaul = the entire codebase, maybe at least be able to point to one file that = really embodies our desired coding standards]. People over process. Code is either readable or it isn=E2=80=99t. If = you are reviewing a PR and the proposed changes are difficult to follow, = a simple and kind explanation is probably more constructive than citing = the offender with the chapter and section of their violation. =20 > On Jun 24, 2019, at 3:31 PM, Alexander Murmann = wrote: >=20 >> Is there an entry in the Coding Standard's Rules section that you = feel is > irrelevant or incorrect? Please pick an example with a link to it so = we can > discuss it. >=20 > I haven't seen any rules in there that I think are irrelevant or = incorrect. > My reasoning is a little different from that: > I think there are two different, competing goals we can optimize for: > a) The rules should be as complete as possible. > b) New contributors should be able to quickly catch up to what the = coding > standard is for this project. >=20 > I'd rather optimize for a) over b). To that end I'd prefer to leave > absolutely valid, but arguably obvious rules like MET02-J. Do not use > deprecated or obsolete classes or methods > = > or IDS00-J. Prevent SQL injection > = > off > and instead highlight the ways we are more opinionated then some other = Java > projects (e.g. "Avoid introducing new statics", "limit method length", > "don't use abbreviated names") >=20 > We could also go down the path of a compromise and highlight the rules = we > care most about that will allow someone who is already a competent > developer to get up to speed quickly on our project and refer to the = SEI > CERT rules as a recommended read for developers who are newer to Java. = The > difference to your proposal would be that the Geode wiki page would > highlight what's most important and potentially surprising rather than = be > an addendum to the already very large corpus of SEI CERT rules. >=20 >=20 > On Mon, Jun 24, 2019 at 3:15 PM Kirk Lund wrote: >=20 >> Java is complicated and Apache Geode is complicated, hence it's a = large >> Coding Standard. *Effective Java* is similarly *large* if you compare = it to >> the *Google Java Style Guide*. >>=20 >> The "*rules*" are "*guidelines*" -- I think you're being too literal. = Also, >> please remember what I said: >>=20 >> I'm not proposing we rigidly and blindly follow this Coding Standard. = We >>> can extend or even supersede portions of the adopted Coding Standard = with >>> our own Addendum. The Coding Standard Addendum would exist on the = Apache >>> Geode Wiki to define Geode-specific rules or recommendations. What = I'd >> like >>> to see happen is for us to use the SEI CERT Coding Standard for Java = as a >>> starting point for our own Coding Standard. The resulting Coding = Standard >>> for Geode can be as static or as living and evolving as we wish. >>>=20 >>=20 >> Is there an entry in the Coding Standard's Rules section that you = feel is >> irrelevant or incorrect? Please pick an example with a link to it so = we can >> discuss it. >>=20 >> PS: There aren't any other Coding Standards that I would personally = write >> or recommend. >>=20 >> On Mon, Jun 24, 2019 at 2:50 PM Alexander Murmann = >> wrote: >>=20 >>> Hi Kirk, >>>=20 >>> I think having a coding standard that goes beyond a formatting style >> guide >>> is a great idea. There are many interesting things in the SEI CERT >>> standard. However, it's also massive. I see 13 rules just about = methods. >>> Yet some guidelines that would be most important to me like limiting >> method >>> length and number of parameters are missing. >>>=20 >>> I wonder if we might be better off taking the rules we like from SEI >> CERT, >>> adding our own and aiming for a much smaller set of guidelines. I'd = hope >>> for something like a one-pager. If it gets much longer than that, it >>> becomes burdensome to read for newcomers and we want to make sure = they >> can >>> quickly take in what's most important. >>>=20 >>> I also prefer "guidelines" over "rules". I'd like to have a = discussion if >>> someone is not following a guideline, rather than creating the = impression >>> that all rules must be followed, no matter what the circumstances = are. >>>=20 >>>=20 >>> On Mon, Jun 24, 2019 at 2:16 PM Kirk Lund wrote: >>>=20 >>>> Apache Geode has a Code Style Guide [1] which is currently defined = as >>>> following the Google Java Style Guide [2]. This style guide is a = good >>>> starting point, but it deals primarily with formatting of code and = is a >>>> fairly dated and static document that doesn't evolve much. >>>>=20 >>>> I'd like to propose that the Geode dev community adopt a Coding >> Standard >>> in >>>> addition to the Style Guide. Specifically, I believe that having = our >>>> community follow the SEI CERT Coding Standard [3] for Java [4] = would >>>> benefit us greatly. There are also Coding Standards for C and C++ = that >> we >>>> could consider if we decide to use the one for Java. >>>>=20 >>>> SEI CERT Coding Standards are completely documented on their wiki = which >>> is >>>> open to having anyone join and become involved in their community. = They >>> are >>>> also available in book form (including on amazon.com). >>>>=20 >>>> =46rom what I've studied, I believe the Coding Standard and Google = Java >>> Style >>>> Guide will be compatible, but we could decide that the Coding = Standard >>>> supersedes anything in the Google Java Style Guide that is directly = in >>>> conflict just in case. >>>>=20 >>>> I'm not proposing we rigidly and blindly follow this Coding = Standard. >> We >>>> can extend or even supersede portions of the adopted Coding = Standard >> with >>>> our own Addendum. The Coding Standard Addendum would exist on the >> Apache >>>> Geode Wiki to define Geode-specific rules or recommendations. What = I'd >>> like >>>> to see happen is for us to use the SEI CERT Coding Standard for = Java >> as a >>>> starting point for our own Coding Standard. The resulting Coding >> Standard >>>> for Geode can be as static or as living and evolving as we wish. >>>>=20 >>>> The Coding Standard can then provide helpful guidance in how we = reshape >>>> some of the Geode code base that is in greater need of refactoring. = It >>>> would also help guide us from following poor examples in the = current >> code >>>> base when introducing new code. >>>>=20 >>>> [1] = https://cwiki.apache.org/confluence/display/GEODE/Code+Style+Guide >>>> [2] https://google.github.io/styleguide/javaguide.html >>>> [3] >>>>=20 >>>>=20 >>>=20 >> = https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standa= rds >>>> [4] >>>>=20 >>>>=20 >>>=20 >> = https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+St= andard+for+Java >>>>=20 >>>=20 >>=20