From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E2EE21387FD for ; Thu, 27 Mar 2014 12:49:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DFFD7E0BFA; Thu, 27 Mar 2014 12:49:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 394D8E0BF3 for ; Thu, 27 Mar 2014 12:49:01 +0000 (UTC) Received: from hackintosh.gkp-asp.local (unknown [195.254.219.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bernalex) by smtp.gentoo.org (Postfix) with ESMTPSA id F15A033F48B for ; Thu, 27 Mar 2014 12:48:59 +0000 (UTC) From: Alexander Berntsen To: gentoo-portage-dev@lists.gentoo.org Subject: [gentoo-portage-dev] [PATCH 1/3] DEVELOPING: Cap at 72 columns Date: Thu, 27 Mar 2014 13:48:38 +0100 Message-Id: <1395924520-9291-2-git-send-email-bernalex@gentoo.org> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1395924520-9291-1-git-send-email-bernalex@gentoo.org> References: <1395924520-9291-1-git-send-email-bernalex@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org X-Archives-Salt: ac5f4ff1-8efe-4b4a-bca2-e1c3cad116a2 X-Archives-Hash: 6a80d6e40666d4ac1df5211e3d8e3165 --- Nothing to see here, move along. DEVELOPING | 71 +++++++++++++++++++++++++++++++++----------------------------- 1 file changed, 38 insertions(+), 33 deletions(-) diff --git a/DEVELOPING b/DEVELOPING index 40b4ca2..1f5087a 100644 --- a/DEVELOPING +++ b/DEVELOPING @@ -1,37 +1,39 @@ Code Guidelines --------------- -A few code guidelines to try to stick to, please comment if none of these make -sense, they are pretty basic and mostly apply to old code. However for people -who are looking at current code, they make take up bad habits that exist in the -current codebase. +A few code guidelines to try to stick to, please comment if none of +these make sense, they are pretty basic and mostly apply to old code. +However for people who are looking at current code, they make take up +bad habits that exist in the current codebase. Python Version -------------- -Python 2.6 is the minimum supported version, since it is the first version to -support Python 3 syntax. All exception handling should use Python 3 'except' -syntax, and the print function should be used instead of Python 2's print -statement (from __future__ import print_function). +Python 2.6 is the minimum supported version, since it is the first +version to support Python 3 syntax. All exception handling should use +Python 3 'except' syntax, and the print function should be used instead +of Python 2's print statement (from __future__ import print_function). Dependencies ------------ -Python and Bash should be the only hard dependencies. Any other dependencies, -including external Python modules that are not included with Python itself, -must be optionally enabled by run-time detection. +Python and Bash should be the only hard dependencies. Any other +dependencies, including external Python modules that are not included +with Python itself, must be optionally enabled by run-time detection. Tabs ---- -The current code uses tabs, not spaces. Keep whitespace usage consistent -between files. New files should use tabs. Space is sometimes used for -indentation in Python code. Tab stop should for this reason be set to 4. +The current code uses tabs, not spaces. Keep whitespace usage +consistent between files. New files should use tabs. Space is +sometimes used for indentation in Python code. Tab stop should for this +reason be set to 4. Line-Wrapping ------------- -Lines should typically not be longer than 80 characters; if they are an attempt -should be made to wrap them. Move code to the line below and indent once (\t). +Lines should typically not be longer than 80 characters; if they are an +attempt should be made to wrap them. Move code to the line below and +indent once (\t). errors.append(MalformedMetadata( errors.DESCRIPTION_TOO_LONG_ERROR % \ @@ -45,9 +47,10 @@ errors.append(MalformedMetadata( (length, max_desc_len), attr='DESCRIPTION.toolong') -The mixing of tabs and spaces means other developers can't read what you did. -This is why the python peps state spaces over tabs; because with spaces the line -wrapping is always clear (but you cannot convert spaces as easily as tabwidth). +The mixing of tabs and spaces means other developers can't read what you +did. This is why the python peps state spaces over tabs; because with +spaces the line wrapping is always clear (but you cannot convert spaces +as easily as tabwidth). Comparisons ----------- @@ -78,9 +81,9 @@ Generally you can do two things here, if you are messing with defaults.. dict.get(foo, some_default) -will try to retrieve foo from dict, if there is a KeyError, will insert foo -into dict with the value of some_default. This method is preferred in cases where -you are messing with defaults: +will try to retrieve foo from dict, if there is a KeyError, will insert +foo into dict with the value of some_default. This method is preferred +in cases where you are messing with defaults: try: dict[foo] @@ -114,7 +117,8 @@ YES: NO: import os,sys,time -When importing from a module, you may import more than 1 thing at a time. +When importing from a module, you may import more than 1 thing at a +time. YES: from portage.module import foo, bar, baz @@ -139,9 +143,9 @@ NO: import sys Try not to import large numbers of things into the namespace of a module. -I realize this is done all over the place in current code but it really makes it -a pain to do code reflection when the namespace is cluttered with identifiers -from other modules. +I realize this is done all over the place in current code but it really +makes it a pain to do code reflection when the namespace is cluttered +with identifiers from other modules. YES: @@ -153,14 +157,15 @@ from portage.output import bold, create_color_func, darkgreen, \ green, nocolor, red, turquoise, yellow The YES example imports the 'output' module into the current namespace. -The negative here is having to use output.COLOR all over the place instead of -just COLOR. However it means during introspection of the current namespace -'green','red', 'yellow', etc. will not show up. +The negative here is having to use output.COLOR all over the place +instead of just COLOR. However it means during introspection of the +current namespace 'green','red', 'yellow', etc. will not show up. -The NO example just imports a set of functions from the output module. It is -somewhat annoying because the import line needs to be modified when functions -are needed and often unused functions are left in the import line until someone -comes along with a linter to clean up (does not happen often). +The NO example just imports a set of functions from the output module. +It is somewhat annoying because the import line needs to be modified +when functions are needed and often unused functions are left in the +import line until someone comes along with a linter to clean up (does +not happen often). Releases -- 1.8.3.2