I'm not arguing that gofmt is necessary; anything that facilitates a
standard, clear format will suffice. However, I maintain that the vala
community would be lucky to have so nice a tool as gofmt. (It really does
fix everything) :-P
On Apr 1, 2013 4:34 PM, "David Gomes" wrote:
> I'm not against
I'm not against prettifiers, I just don't see the need for something like
gofmt that aligns comments, indents with tabs and "supposedly" fixes
everything.
I'm sure vala-analyzer is good for what we need now and we have other
priorities now, but maybe one of these days somebody makes a prettifier,
That's great. It seemed as though you were against a prettifier when you've
been using one all along! The next logical step is to migrate to a
dedicated tool (one that is not bound to a certain editor) so users are
free to use the editor of their liking.
If such a tool is available (and is suffici
Dane, it will only breed lazy practices in the arena of style, which is a
non issue because said beautifier will correct all such issues. Style isn't
something any one needs to be disciplined in for the same reasons we no
longer have to be disciplined about writing in assembly: we have automated
to
And that's why I use an editor that formats certain things about code for
me.
On Mon, Apr 1, 2013 at 10:13 PM, Craig wrote:
> I think you misunderstand me. A prettifier doesn't force the user's style
> on the project, but it changes the format of the pushed code to match that
> of the project s
I think you misunderstand me. A prettifier doesn't force the user's style
on the project, but it changes the format of the pushed code to match that
of the project so, for instance, other elementary developers aren't plagued
by my style and I don't have to mentally manage a conversion between my
wo
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 wrote:
> I understand the hesitance to push lovingly crafted code through a
> cookie-cutter code beautifier, but we are ha
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_JEhGrdeshRQP5oBudh7IPQJeeux
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
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
curr
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 wrote:
> The more I read threads like this the more it se
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" wrote:
> I agree with Victor. Consistency matters because it makes readability and
> therefore maintainability better.
>
> --
> Jaap
> Op 1 apr. 2013 09:09 schreef "
I agree with Victor. Consistency matters because it makes readability and
therefore maintainability better.
--
Jaap
Op 1 apr. 2013 09:09 schreef "Victor" het
volgende:
> Coding style is a subjective topic, and that's why discussing which one
> works best is completely pointless, since it's a mat
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 elem
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" <
ser...@elementaryos.org> 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
> I wrote th
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 kno
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" wrote:
> Cool, it's pretty thorough.
>
>
> On Wed, Mar 27, 2013 at 7:58 AM, David Gomes wrote:
>
>> http://dl.dropbox.com/u/19899464/
Cool, it's pretty thorough.
On Wed, Mar 27, 2013 at 7:58 AM, David Gomes 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 tutoria
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
20 matches
Mail list logo
