From owner-freebsd-chat@FreeBSD.ORG Mon Apr 13 09:09:45 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5FC1065740 for ; Mon, 13 Apr 2009 09:09:42 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 6E20F8FC18 for ; Mon, 13 Apr 2009 09:09:42 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by fxm11 with SMTP id 11so1933332fxm.43 for ; Mon, 13 Apr 2009 02:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=xwzTMQL9D/zrC2yJWse/tE96MevpYdP4ExcNU3SzNac=; b=xniZAA5DDPk/VPLx0M5EmIf/bREGlAhQBsIh/EQKgb/rRed5uqulrpWZZkCCvb9/Dt rpqC4rIfTSr0uUr7uXd3EHCwJLVxPYzR/mFjG0ZPxioke5KNn9qDO8wrzsAQistXE/ZE f2R8p6N1dcQHK2NuDyGaj84WKSjauyKMfvI6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=h6XycSohITyc72WEYiRUgUgbjZ7qYQzMjj7u4M93zLrvEJD0oCHUwD/C5+kOmT4tSA L/nVwPiFOPS2TSp3KlynY0bxCQxfb+2D9FtO9wxSHcZ9cxB8IMIQRRU0ZJ7KljTqD9kH p3cRQT0W+sjFluzFT1lmOefr5jwH+gw0j/NIM= Received: by 10.103.182.3 with SMTP id j3mr3190690mup.113.1239612312604; Mon, 13 Apr 2009 01:45:12 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 12sm9334199muq.35.2009.04.13.01.45.10 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 01:45:11 -0700 (PDT) Message-ID: <49E2FBE2.8020305@gmail.com> Date: Mon, 13 Apr 2009 10:46:26 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 MultiZilla/1.8.3.4e SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-chat@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: My whitespace style (was: Why?? (prog question)) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 09:09:46 -0000 Tabs are better, because they allow the programmer to specify the desired width, and is dynamically changable at any time. Width could be geared towards a purpose, for example: I've read somewhere that the linux kernel guide recommends 8 characters per tab, because the distance clearly separates levels, and warns the coder if statements are nested too deep. So a linux kernel programmer sets the tab with to 8, while another programmer with a small monitor prefers 4 to see code like "if(..) { if(..) { if(..) { if(..) { if(..) { if(..) { ...". This is all possible without text processing programs that convert indentation sizes required if the code were hard-indented with spaces. Tabs are to be considered non-constant in width. Specifically they should be used for and only for indentation. So here's my style. First, a display with a tab-size of 8. The arrows ("------->") denote tabs. struct datatype { ------->int field_one; // this is the ... ------->int field_two; // this contains ... -------> ------->long long int field_three; // and this one is used for ... ------->long long int field_four; // this one is useless }; void function( int x ) { ------->if( x > 1234567891011121314 ) { ------->------->do_something(); ------->------->do_something_else(); ------->} ------->else { ------->------->do_something_else(); ------->------->do_something(); ------->} -------> ------->assert( c89_is_outdated ); -------> ------->struct datatype data; -------> ------->while( check_me_first() && then_check_me() || -------> read(&data) && data.field_three > x ) ------->{ ------->------->do_something(); ------->------->x = x + 2*x + 4*x*x + 5*x*x*x + 5*x*x*x*x ------->-------> + x*x*x*x*x*x - 9*x*x*x*x*x*x*x; ------->} } The same code with 4 spaces per tab: struct datatype { --->int field_one; // this is the ... --->int field_two; // this contains ... ---> --->long long int field_three; // and this one is used for ... --->long long int field_four; // this one is useless }; void function( int x ) { --->if( x > 1234567891011121314 ) { --->--->do_something(); --->--->do_something_else(); --->} --->else { --->--->do_something_else(); --->--->do_something(); --->} ---> --->assert( c89_is_outdated ); ---> --->struct datatype data; ---> --->while( check_me_first() && then_check_me() || ---> read(&data) && data.field_three > x ) --->{ --->--->do_something(); --->--->x = x + 2*x + 4*x*x + 5*x*x*x + 5*x*x*x*x --->---> + x*x*x*x*x*x - 9*x*x*x*x*x*x*x; --->} } For every left curly brace, the indentation increases, as the number of tabs on a line. But take a look at the loop: It has level 1 nesting, but the condition is as long as 2 lines. The second line of the condition is indented properly by 1 tab, and is polished a bit by spaces. Finally, I find it more readable to put the left curly brace on a new line for such long conditions. I like the idea of writing appropriate amount of tabs for empty lines too, it could possibly make a diff output readable (note even the additional spaces in the empty line of the struct definition). Although I haven't used it in practice. On a side note, I use spaces inside the outermost parentheses, but not in the deeper ones. I rarely write "} else {" on one line. Everything else I can think of is based on opinion and good looks. Finally, another possible definition of the struct: struct datatype { ------->int field_one; ------->// this is the ... ------->int field_two; ------->// this contains ... -------> -------> ------->long long int field_three;------->// and this one is used for ... ------->long long int field_four; ------->// this one is useless }; Elastic tabstops look cool, they are just what I need. I'm open to critics.