From angvp@archlinux.com.ve Fri Jun 20 01:54:25 2008 From: Angel =?utf-8?q?Vel=C3=A1squez?= To: aur-dev@lists.archlinux.org Subject: [aur-dev] AUR Coding recomendations IMPORTANT Date: Fri, 20 Jun 2008 07:54:24 +0200 Message-ID: <330e48780806192254t64e1ecb0he192cef10618eb60@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7881427198955163083==" --===============7881427198955163083== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, I am writing this e-mail after reviewing the AUR code and some patches that people have been sending. As we know, AUR (like many applications) is still in development, and many of the things that are actually working weren't coded by any of us, and I can understand this. The purpose of my e-mail is to give some recommendations that should be adopted by everyone, I don't want to be arrogant or force you to do something without knowing why, so I will explain the reasons behind my recommendations and then you will probably agree with me. Singles quotes vs Doubles quotes ===================== Problem: In the past I sent an e-mail about this topic, but I think I was misunderstood. The correct way should be using singles quotes when you don't need to parse any kind of variable, that applies in any case. Examples: 1.- include "lib/whatever.inc.php"; // why double quotes ? just to waste resources and no more.. 2.- function myFunction($var) { return "Hello ".$var; // wrong concatenation AND using double quotes ?! # return 'Hello '.$var; // this is the correct use } echo myFunction("world"); // wrong # echo myFunction('world'); // Oh nice you know what i'm talking about. 3.- $_SESSION["myName"] = "MyNameIsWrong"; // and it certainly is wrong, thanks for wasting resources with double quotes! # $_SESSION['myName'] = 'Foo Bar'; // that's the way 4.- // the last example of a block of HTML print "\n"; print "\n"; print "\n"; print "\n"; print "
".$title."
\n"; // Come on!!!!, the following line does the same. echo "\n\n\n\n
$title
"; // Yes I know that placing plenty of \n's would render the code unreadable, but you can do it in one line with a simple echo. Overview: I recommend the use of double quotes in the case that you need to parse many variables so that the code doesn't become unreadable, or if you want to output HTML code in a sorted way. print vs echo ======== Problem: Many of us usually prefer to use print because we are used to the function name similarities from languages other than PHP, and we can't get used to *not* using it. Examples: 1.- print 'echo is ugly!'; // assuming that you've learned about singles and doubles quotes :D Overview: Print outputs the string and has an actual return value of TRUE or FALSE, so that converts print in a function slower than echo. See this thread for more information: http://codingforums.com/archive/index.php?t-41745.html To wrap this up, I just want to emphasize the fact that whereas this might look trivial and nearly irrelevant to some of you, it is important in order to make AUR a better tool. Cheers. -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 Arch Linux Trusted User --===============7881427198955163083== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 SGksIEkgYW0gd3JpdGluZyB0aGlzIGUtbWFpbCBhZnRlciByZXZpZXdpbmcgdGhlIEFVUiBjb2Rl IGFuZCBzb21lIHBhdGNoZXMgdGhhdCBwZW9wbGUgaGF2ZSBiZWVuIHNlbmRpbmcuPGJyPjxicj5B cyB3ZSBrbm93LCBBVVIgKGxpa2UgbWFueSBhcHBsaWNhdGlvbnMpIGlzIHN0aWxsIGluIGRldmVs b3BtZW50LCBhbmQgbWFueSBvZiB0aGUgdGhpbmdzIHRoYXQgYXJlIGFjdHVhbGx5IHdvcmtpbmcg d2VyZW4mIzM5O3QgY29kZWQgYnkgYW55IG9mIHVzLCBhbmQgSSBjYW4gdW5kZXJzdGFuZCB0aGlz Ljxicj4KPGJyPlRoZSBwdXJwb3NlIG9mIG15IGUtbWFpbCBpcyB0byBnaXZlIHNvbWUgcmVjb21t ZW5kYXRpb25zIHRoYXQgc2hvdWxkIGJlIGFkb3B0ZWQgYnkgZXZlcnlvbmUsIEkgZG9uJiMzOTt0 IHdhbnQgdG8gYmUgYXJyb2dhbnQgb3IgZm9yY2UgeW91IHRvIGRvIHNvbWV0aGluZyB3aXRob3V0 IGtub3dpbmcgd2h5LCBzbyBJIHdpbGwgZXhwbGFpbiB0aGUgcmVhc29ucyBiZWhpbmQgbXkgcmVj b21tZW5kYXRpb25zIGFuZCB0aGVuIHlvdSB3aWxsIHByb2JhYmx5IGFncmVlIHdpdGggbWUuPGJy Pgo8YnI+PGJyPjxicj5TaW5nbGVzIHF1b3RlcyB2cyBEb3VibGVzIHF1b3Rlczxicj49PT09PT09 PT09PT09PT09PT09PT08YnI+PGJyPlByb2JsZW06PGJyPjxicj5JbiB0aGUgcGFzdCBJIHNlbnQg YW4gZS1tYWlsIGFib3V0IHRoaXMgdG9waWMsIGJ1dCBJIHRoaW5rIEkgd2FzIG1pc3VuZGVyc3Rv b2QuIFRoZSBjb3JyZWN0IHdheSBzaG91bGQgYmUgdXNpbmcgc2luZ2xlcyBxdW90ZXMgd2hlbiB5 b3UgZG9uJiMzOTt0IG5lZWQgdG8gcGFyc2UgYW55IGtpbmQgb2YgdmFyaWFibGUsIHRoYXQgYXBw bGllcyBpbiBhbnkgY2FzZS48YnI+Cjxicj5FeGFtcGxlczo8YnI+PGJyPjEuLTxicj5pbmNsdWRl ICZxdW90O2xpYi93aGF0ZXZlci5pbmMucGhwJnF1b3Q7OyAvLyB3aHkgZG91YmxlIHF1b3RlcyA/ IGp1c3QgdG8gd2FzdGUgcmVzb3VyY2VzIGFuZCBubyBtb3JlLi48YnI+PGJyPjIuLTxicj5mdW5j dGlvbiBteUZ1bmN0aW9uKCR2YXIpIHs8YnI+Jm5ic3A7Jm5ic3A7IHJldHVybiAmcXVvdDtIZWxs byAmcXVvdDsuJHZhcjsgLy8gd3JvbmcgY29uY2F0ZW5hdGlvbiBBTkQgdXNpbmcgZG91YmxlIHF1 b3RlcyA/ITxicj4KJm5ic3A7ICMgcmV0dXJuICYjMzk7SGVsbG8gJiMzOTsuJHZhcjsgLy8gdGhp cyBpcyB0aGUgY29ycmVjdCB1c2U8YnI+PGJyPn08YnI+ZWNobyBteUZ1bmN0aW9uKCZxdW90O3dv cmxkJnF1b3Q7KTsgLy8gd3Jvbmc8YnI+IyBlY2hvIG15RnVuY3Rpb24oJiMzOTt3b3JsZCYjMzk7 KTsgLy8gT2ggbmljZSB5b3Uga25vdyB3aGF0IGkmIzM5O20gdGFsa2luZyBhYm91dC48YnI+PGJy PjMuLTxicj4kX1NFU1NJT05bJnF1b3Q7bXlOYW1lJnF1b3Q7XSA9ICZxdW90O015TmFtZUlzV3Jv bmcmcXVvdDs7IC8vIGFuZCBpdCBjZXJ0YWlubHkgaXMgd3JvbmcsIHRoYW5rcyBmb3Igd2FzdGlu ZyByZXNvdXJjZXMgd2l0aCBkb3VibGUgcXVvdGVzITxicj4KPGJyPiMgJF9TRVNTSU9OWyYjMzk7 bXlOYW1lJiMzOTtdID0gJiMzOTtGb28gQmFyJiMzOTs7IC8vIHRoYXQmIzM5O3MgdGhlIHdheTxi cj48YnI+NC4tPGJyPi8vIHRoZSBsYXN0IGV4YW1wbGUgb2YgYSBibG9jayBvZiBIVE1MPGJyPnBy aW50ICZxdW90OyZsdDt0YWJsZSZndDtcbiZxdW90Ozs8YnI+cHJpbnQgJnF1b3Q7Jmx0O3RyJmd0 O1xuJnF1b3Q7Ozxicj5wcmludCAmcXVvdDsmbHQ7dGQmZ3Q7JnF1b3Q7LiR0aXRsZS4mcXVvdDsm bHQ7L3RkJmd0O1xuJnF1b3Q7Ozxicj4KcHJpbnQgJnF1b3Q7Jmx0Oy90ciZndDtcbiZxdW90Ozs8 YnI+cHJpbnQgJnF1b3Q7Jmx0Oy90YWJsZSZndDtcbiZxdW90Ozs8YnI+Ly8gQ29tZSBvbiEhISEs IHRoZSBmb2xsb3dpbmcgbGluZSBkb2VzIHRoZSBzYW1lLjxicj48YnI+PGJyPmVjaG8gJnF1b3Q7 Jmx0O3RhYmxlJmd0O1xuJmx0O3RyJmd0O1xuJmx0O3RkJmd0OyR0aXRsZSZsdDsvdGQmZ3Q7XG4m bHQ7L3RyJmd0O1xuJmx0Oy90YWJsZSZndDsmcXVvdDs7PGJyPgovLyBZZXMgSSBrbm93IHRoYXQg cGxhY2luZyBwbGVudHkgb2YgXG4mIzM5O3Mgd291bGQgcmVuZGVyIHRoZSBjb2RlIHVucmVhZGFi bGUsIGJ1dCB5b3UgY2FuIGRvIGl0IGluIG9uZSBsaW5lIHdpdGggYSBzaW1wbGUgZWNoby48YnI+ PGJyPk92ZXJ2aWV3Ojxicj48YnI+SSByZWNvbW1lbmQgdGhlIHVzZSBvZiBkb3VibGUgcXVvdGVz IGluIHRoZSBjYXNlIHRoYXQgeW91IG5lZWQgdG8gcGFyc2UgbWFueSB2YXJpYWJsZXMgc28gdGhh dCB0aGUgY29kZSBkb2VzbiYjMzk7dCBiZWNvbWUgdW5yZWFkYWJsZSwgb3IgaWYgeW91IHdhbnQg dG8gb3V0cHV0IEhUTUwgY29kZSBpbiBhIHNvcnRlZCB3YXkuPGJyPgo8YnI+cHJpbnQgdnMgZWNo bzxicj49PT09PT09PTxicj48YnI+UHJvYmxlbTo8YnI+PGJyPk1hbnkgb2YgdXMgdXN1YWxseSBw cmVmZXIgdG8gdXNlIHByaW50IGJlY2F1c2Ugd2UgYXJlIHVzZWQgdG8gdGhlIGZ1bmN0aW9uIG5h bWUgc2ltaWxhcml0aWVzIGZyb20gbGFuZ3VhZ2VzIG90aGVyIHRoYW4gUEhQLCBhbmQgd2UgY2Fu JiMzOTt0IGdldCB1c2VkIHRvICpub3QqIHVzaW5nIGl0Ljxicj4KPGJyPjxicj5FeGFtcGxlczo8 YnI+PGJyPjEuLSBwcmludCAmIzM5O2VjaG8gaXMgdWdseSEmIzM5OzsgLy8gYXNzdW1pbmcgdGhh dCB5b3UmIzM5O3ZlIGxlYXJuZWQgYWJvdXQgc2luZ2xlcyBhbmQgZG91YmxlcyBxdW90ZXMgOkQ8 YnI+PGJyPk92ZXJ2aWV3Ojxicj48YnI+UHJpbnQgb3V0cHV0cyB0aGUgc3RyaW5nIGFuZCBoYXMg YW4gYWN0dWFsIHJldHVybiB2YWx1ZSBvZiBUUlVFIG9yIEZBTFNFLCBzbyB0aGF0IGNvbnZlcnRz IHByaW50IGluIGEgZnVuY3Rpb24gc2xvd2VyIHRoYW4gZWNoby48YnI+Cjxicj48YnI+U2VlIHRo aXMgdGhyZWFkIGZvciBtb3JlIGluZm9ybWF0aW9uOiA8YSBocmVmPSJodHRwOi8vY29kaW5nZm9y dW1zLmNvbS9hcmNoaXZlL2luZGV4LnBocD90LTQxNzQ1Lmh0bWwiPmh0dHA6Ly9jb2Rpbmdmb3J1 bXMuY29tL2FyY2hpdmUvaW5kZXgucGhwP3QtNDE3NDUuaHRtbDwvYT48YnI+PGJyPlRvIHdyYXAg dGhpcyB1cCwgSSBqdXN0IHdhbnQgdG8gZW1waGFzaXplIHRoZSBmYWN0IHRoYXQgd2hlcmVhcyB0 aGlzIG1pZ2h0IGxvb2sgdHJpdmlhbCBhbmQgbmVhcmx5IGlycmVsZXZhbnQgdG8gc29tZSBvZiB5 b3UsIGl0IGlzIGltcG9ydGFudCBpbiBvcmRlciB0byBtYWtlIEFVUiBhIGJldHRlciB0b29sLjxi cj4KPGJyPkNoZWVycy48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+QW5nZWwgVmVs4XNx dWV6PGJyPmFuZ3ZwIEAgPGEgaHJlZj0iaHR0cDovL2lyYy5mcmVlbm9kZS5uZXQiPmlyYy5mcmVl bm9kZS5uZXQ8L2E+PGJyPkxpbnV4IENvdW50ZXI6ICMzNTk5MDkgPGJyPkFyY2ggTGludXggVHJ1 c3RlZCBVc2VyCg== --===============7881427198955163083==-- From louipc.ist@gmail.com Fri Jun 20 02:27:36 2008 From: Loui To: aur-dev@lists.archlinux.org Subject: Re: [aur-dev] AUR Coding recomendations IMPORTANT Date: Fri, 20 Jun 2008 02:26:21 -0400 Message-ID: <20080620062621.GD7510@lynn.lan> In-Reply-To: <330e48780806192254t64e1ecb0he192cef10618eb60@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0435851832129131827==" --===============0435851832129131827== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 20, 2008 at 07:54:24AM +0200, =3D?ISO-8859-1?Q?Angel_Vel=3DE1sque= z_ wrote: > Hi, I am writing this e-mail after reviewing the AUR code and some patches > that people have been sending. >=20 > As we know, AUR (like many applications) is still in development, and many > of the things that are actually working weren't coded by any of us, and I > can understand this. =20 I think AUR is more in maintenance mode more than development mode. Developers of AUR have been envisioning a better system for awhile but just haven't quite gotten to it. I really just want to get AUR to a cool state where I can devote time to developing an even awesomer system than what currently exists. Hey maybe you could be the next maintainer if you send enough patches. *wink wink* > The purpose of my e-mail is to give some recommendations that should be > adopted by everyone, I don't want to be arrogant or force you to do > something without knowing why, so I will explain the reasons behind my > recommendations and then you will probably agree with me. [...]=20 > 4.- > // the last example of a block of HTML > print "\n"; > print "\n"; > print "\n"; > print "\n"; > print "
".$title."
\n"; > // Come on!!!!, the following line does the same. >=20 >=20 > echo "\n\n\n\n
$title
"; > // Yes I know that placing plenty of \n's would render the code unreadable, > but you can do it in one line with a simple echo. A much better way to clean this up would be:
And that's what we're trying to do. Just take as much HTML out of PHP as possible. =20 Thanks for your suggestions. Rock on. --===============0435851832129131827==-- From chi@chimeric.de Fri Jun 20 17:30:20 2008 From: chi@chimeric.de To: aur-dev@lists.archlinux.org Subject: Re: [aur-dev] AUR Coding recomendations IMPORTANT Date: Fri, 20 Jun 2008 23:30:20 +0200 Message-ID: In-Reply-To: <330e48780806192254t64e1ecb0he192cef10618eb60@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6254483461463625506==" --===============6254483461463625506== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Angel Vel=C3=A1squez writes: > The purpose of my e-mail is to give some recommendations that should be=20 > adopted by everyone, I don't want to be arrogant or force you to do=20 > something without knowing why, so I will explain the reasons behind my=20 > recommendations and then you will probably agree with me. >=20 > Singles quotes vs Doubles quotes >=20 > Problem: >=20 > In the past I sent an e-mail about this topic, but I think I was=20 > misunderstood. The correct way should be using singles quotes when you=20 > don't need to parse any kind of variable, that applies in any case. As I feel a little bit addressed by that (read addressed not offended ;-)) I'd like to repeat again that I completely understand your points (and understood them in the prior mails too ;)). I am currently maintaining around 25.000 lin= es of PHP code (which is not all written by me), and trust me, I know what good coding style is worth (personally I stick to the Zend Framework PHP coding standards [1] whenever possible when it comes to PHP). But, as you already said some source code files of the AUR are not really in shape in many ways when it comes to coding standards. The problem, as I see it for someone who likes to send a patch, is, that you usually address a specific "problem" with a patch. Although cleaning the code makes always sense, it should IMHO be separated into separate patch sets and not mixed with other patches in order to not blur the "real" purpose of a patch. I actually sent one patch which did both, fix some invalid XHTML + refactored the rest of the file. It was rejected because it was too big and you couldn't really tell from the diff what was actually fixed and what was just moved a b= it here and there. I think the cleaning of the code is a task of it's own and should not be mixed with fixes for specific problems. Even though the changes I've sent until now where small, I also agree with Loui, when he says the AUR is more in maintenance mode (IIRC there where already two attempts for AUR2, though I don't know much about their current state). Again, I'd just like to say that I believe we're thinking along the same lines :). Best Regards, Michael [1] http://framework.zend.com/manual/en/coding-standard.html --===============6254483461463625506== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.sig" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCgppRVlFQUJFQ0FBWUZBa2hjSVd3QUNna1FBdUwxaTRNSTlWRXZtZ0NlSjBwMEIzRXdm ZE91d3c3LzFmNW5MSmc3CnUwOEFuMjk5eXp5S1pOKzlhVXAyN1M2WnFvakcrSndRCj0wWUZHCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============6254483461463625506==-- From louipc.ist@gmail.com Fri Jun 20 18:33:48 2008 From: Loui To: aur-dev@lists.archlinux.org Subject: Re: [aur-dev] AUR Coding recomendations IMPORTANT Date: Fri, 20 Jun 2008 18:32:42 -0400 Message-ID: <20080620223242.GA18118@lynn.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9094553198876523423==" --===============9094553198876523423== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 20, 2008 at 11:30:20PM +0200, chi(a)chimeric.de wrote: > But, as you already said some source code files of the AUR are not really in > shape in many ways when it comes to coding standards. The problem, as I see= it > for someone who likes to send a patch, is, that you usually address a speci= fic > "problem" with a patch. Although cleaning the code makes always sense, it > should IMHO be separated into separate patch sets and not mixed with other > patches in order to not blur the "real" purpose of a patch. Yep that's the idea. Ooh. I hadn't even thought of this: From: http://framework.zend.com/manual/en/coding-standard.html > For files that contain only PHP code, the closing tag ("?>") is never > permitted. It is not required by PHP. Not including it prevents trailing > whitespace from being accidentally injected into the output.=20 That's an easy fix that might prevent some issues from popping up. The rss broke once because of a newline somewhere. --===============9094553198876523423==-- From sebnow@gmail.com Sat Jun 21 00:15:58 2008 From: Sebastian Nowicki To: aur-dev@lists.archlinux.org Subject: Re: [aur-dev] AUR Coding recomendations IMPORTANT Date: Sat, 21 Jun 2008 12:15:25 +0800 Message-ID: <6FDA1392-82DB-43EC-A2B2-95162C2887E3@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2619024637369994821==" --===============2619024637369994821== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 21/06/2008, at 5:30 AM, chi(a)chimeric.de wrote: > Even though the changes I've sent until now where small, I also > agree with > Loui, when he says the AUR is more in maintenance mode (IIRC there > where > already two attempts for AUR2, though I don't know much about their > current > state). Being the main dev of the second attempt at AUR2, I'd like to know as well :P. I think sticking to coding conventions is a good idea. Developers should be disciplined and strictly adhere to them, it really does make maintenance easier. I'd be great if people also wrote doxygen/phpdoc documentation to make maintenance and later development much, much easier. It doesn't matter if the code won't be used by anyone else, internal documentation is also very useful. Having said that, I don't know if a lot of effort should be put into fixing up the current code base (especially technical writing). I think everyone agrees that the AUR needs a rewrite. > The problem, as I see it for someone who likes to send a patch, is, > that > you usually address a specific "problem" with a patch. Although > cleaning > the code makes always sense, it should IMHO be separated into separate > patch sets and not mixed with other patches in order to not blur the > "real" purpose of a patch. I don't really see a problem with fixing up the code in terms of conventions along with other changes, as long as only the lines of code that would be changed either way are fixed up. If you go and change a bunch of other code, then that really should be in a separate patch. Of course when cherry-picking patches or something, it sometimes is nicer to have very specific patches, so that it would be possible to apply the "code standard adhering" patch to some other branch. --===============2619024637369994821==--