elementary-dev-community team mailing list archive

[David Gomes <david@xxxxxxxxxxxxxxxx>]

Also, I just noticed the automatic conversion to HTML from Libreoffice was
pretty bad, I'll do it myself this week, so I attached the .odt here.


On Mon, Apr 1, 2013 at 7:49 PM, David Gomes <david@xxxxxxxxxxxxxxxx> wrote:

> http://dl.dropbox.com/u/19899464/elementaryos_coding_style.html
>
> It's this one, not sure if somebody put it up on a Google Docs.
>
>
> On Mon, Apr 1, 2013 at 7:36 PM, Dane Henson <dane@xxxxxxxxxxxxxxxx> wrote:
>
>> I understand the hesitance to push lovingly crafted code through a
>> cookie-cutter code beautifier, but we are hardly talking about chopping
>> everything apart and putting it together backwards.  The only document I
>> know of (
>> https://docs.google.com/document/d/1AcuFhcuEkoEM5_JEhGrdeshRQP5oBudh7IPQJeeuxHQ<https://docs.google.com/document/d/1AcuFhcuEkoEM5_JEhGrdeshRQP5oBudh7IPQJeeuxHQ/edit>)
>> talks about simple rules like whitespace, naming conventions, and the
>> pre-amble "using" statements.
>>
>> This stuff can get controversial, but having clean, consistent code
>> between projects can make it much easier for newer developers like me take
>> a bite out of the code without curling up into a ball and crying in the
>> corner at the EOF.
>>
>> My opinion is that we should strive to add a code formatting phase at the
>> end of our workflow _before_ requesting a merge to make it easier for the
>> reviewer.  If it becomes too cumbersome, I don't have any major qualms with
>> an automated formatting script _as a last resort_.  An automated system
>> could breed lazy programming practices, or even introduce bugs if not
>> implemented properly.  However, unification is better than fragmentation.
>>  It's why we chose a common programming language to begin with, right?
>>
>> A disciplined programmer is an invaluable programmer, especially when it
>> comes to mundane details like this.
>>
>> (please don't look at my personal projects as an example of good code...
>> nobody is perfect :P)
>>
>>
>> On Mon, Apr 1, 2013 at 1:10 PM, Victor <victoreduardm@xxxxxxxxx> wrote:
>>
>>> You're right Craig, although there's something I still don't understand:
>>> Why would somebody want elementary to adapt his/her coding style.
>>>
>>> It's fine if developers focus on the logic first, using their own coding
>>> style, but as a final step those developers should also make sure that
>>> their code is consistent with the rest of the code in the project they're
>>> working on. Shouldn't we as developers review and test our own code before
>>> proposing a patch anyway? We can always adapt the style of new code during
>>> that self-review, before making our work available to be reviewed by others.
>>>
>>> On Mon, Apr 1, 2013 at 8:51 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>>
>>> Personally, I like that I can write code without thinking about the
>>> style and then have it styled automatically when I push. It lets me focus
>>> on the logic of my program rather than whether it obeys a style guideline.
>>> This is especially useful because I participate in projects involving
>>> several current languages and each with its own style guideline.
>>>
>>> I'm not saying we need something like gofmt, but it's foolish to imply
>>> that such a tool is useless (especially when we are manually investing time
>>> correcting code that could be done automatically).
>>>
>>> If an appropriate tool doesn't exist, I don't recommend developing one,
>>> but I don't see how you can mock gofmt when I can validate my style with no
>>> overhead whatsoever while you are doing it manually. Lol. ;-)
>>> On Apr 1, 2013 9:28 AM, "David Gomes" <david@xxxxxxxxxxxxxxxx> wrote:
>>>
>>>> Fortunately, most of the developers can write good code. And when they
>>>> fail to do so we have other developers who review their code.
>>>>
>>>> We don't need a fancy tool like gofmt that just changes our code.
>>>>
>>>>
>>>> On Mon, Apr 1, 2013 at 3:25 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>
>>>>> The more I read threads like this the more it seems elementary should
>>>>> migrate to Go. :-P
>>>>> On Apr 1, 2013 3:29 AM, "Jaap Broekhuizen" <jaapz.b@xxxxxxxxx> wrote:
>>>>>
>>>>>> I agree with Victor. Consistency matters because it makes readability
>>>>>> and therefore maintainability better.
>>>>>>
>>>>>> --
>>>>>> Jaap
>>>>>> Op 1 apr. 2013 09:09 schreef "Victor" <victoreduardm@xxxxxxxxx> het
>>>>>> volgende:
>>>>>>
>>>>>>> Coding style is a subjective topic, and that's why discussing which
>>>>>>> one works best is completely pointless, since it's a matter of preferences.
>>>>>>> It's like discussing what is the best color.
>>>>>>>
>>>>>>> What is important is consistency, and that's why all the new code
>>>>>>> proposed for merging should follow elementary's coding style guidelines
>>>>>>> (which are not published anywhere in the site as far as I know). Whenever
>>>>>>> you propose code that is styled inconsistently it only gives the impression
>>>>>>> that you were coding in a hurry, and we don't want to accept that kind of
>>>>>>> code, even though we have a ton of it already.
>>>>>>>
>>>>>>> Thanks for your attention,
>>>>>>> Victor.
>>>>>>>
>>>>>>> On Sun, Mar 31, 2013 at 12:48 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>> How do you figure? The go language community uses one and they rave
>>>>>>> about it. We use them at work (c++) as well and its uses an obnoxious
>>>>>>> style, but it's still more readable than a dozen different conventions.
>>>>>>> On Mar 31, 2013 5:39 AM, "Sergey "Shnatsel" Davidoff" <
>>>>>>> sergey@xxxxxxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> I'm afraid automatic "prettifiers" are a terrible idea because
>>>>>>>> blindly restyling the code usually makes it lose any remains of readability
>>>>>>>> it used to have. In other words, automatically restyled code is even less
>>>>>>>> readable than code with a foreign coding style.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/3/31 David Gomes <david@xxxxxxxxxxxxxxxx>
>>>>>>>>
>>>>>>>>> I wrote this in order to check for code style errors, but it's not
>>>>>>>>> perfect it's just a help-tool:
>>>>>>>>>
>>>>>>>>> https://github.com/elementary/vala-analyzer
>>>>>>>>>
>>>>>>>>> We have 'considered' using a prettifier too, but I just use Emacs
>>>>>>>>> to fix some stuff on my code - a prettifier script would be too much work
>>>>>>>>> and I don't know of any libraries that would help me with the task.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Mar 31, 2013 at 3:34 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>>>>
>>>>>>>>>> Good work David. Have you (elementary) considered using a
>>>>>>>>>> prettifier to standardize a code style upon pushing to your trunk?
>>>>>>>>>>  On Mar 28, 2013 7:17 PM, "Cody Garver" <cody@xxxxxxxxxxxxxxxx>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Cool, it's pretty thorough.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 27, 2013 at 7:58 AM, David Gomes <
>>>>>>>>>>> david@xxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> http://dl.dropbox.com/u/19899464/reviewstutorial.html
>>>>>>>>>>>>
>>>>>>>>>>>> Hello guys,
>>>>>>>>>>>>
>>>>>>>>>>>> From time to time somebody still has doubts on how to use
>>>>>>>>>>>> Launchpad and Bazaar to review and merge branches to trunk so I wrote a
>>>>>>>>>>>> tutorial. Note though that it may need expansion.
>>>>>>>>>>>>
>>>>>>>>>>>> Many times, even experienced developers who have been in the
>>>>>>>>>>>> Apps Team for a long time make mistakes so even if you already know how to
>>>>>>>>>>>> do it, reading the tutorial won't hurt.
>>>>>>>>>>>>
>>>>>>>>>>>> I also recommend that all developers that in the future are to
>>>>>>>>>>>> join the Apps Team read this several times because even though we can
>>>>>>>>>>>> always revert messed-up commits, it's better to do it right at the first
>>>>>>>>>>>> time.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> David "Munchor" Gomes
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Cody Garver
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sergey "Shnatsel" Davidoff
>>>>>>>> OS architect @ elementary
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>> --
>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

Attachment: elementaryos_coding_style.odt
Description: application/vnd.oasis.opendocument.text