Re: [Elementary-dev-community] How to review and merge branches
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 webe...@gmail.com 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 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 da...@elementaryos.org 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 webe...@gmail.com 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 c...@elementaryos.org wrote: Cool, it's pretty thorough. On Wed, Mar 27, 2013 at 7:58 AM, David Gomes da...@elementaryos.org 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] How to review and merge branches
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 webe...@gmail.com 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 da...@elementaryos.org 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 webe...@gmail.com 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 jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com 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 webe...@gmail.com 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 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 da...@elementaryos.org 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 webe...@gmail.com 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 c...@elementaryos.org wrote: Cool, it's pretty thorough. On Wed, Mar 27, 2013 at 7:58 AM, David Gomes da...@elementaryos.org 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@lists.launchpad.net Unsubscribe :
Re: [Elementary-dev-community] How to review and merge branches
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 webe...@gmail.com 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 so, for instance, other elementary developers aren't plagued by my style and I don't have to mentally manage a conversion between my work style, my personal style, and the styles of the various projects in which I participate. Yes we should review and test or own code, but we should know enough to leverage the accuracy and speed of software for frequent and mundane tasks like reformatting code. On Apr 1, 2013 1:11 PM, Victor victoredua...@gmail.com 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 webe...@gmail.com 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 da...@elementaryos.org 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 webe...@gmail.com 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 jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com 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 webe...@gmail.com 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 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 da...@elementaryos.org 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 webe...@gmail.com 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 c...@elementaryos.org wrote: Cool, it's pretty thorough. On Wed, Mar 27, 2013 at 7:58 AM, David Gomes da...@elementaryos.org wrote:
Re: [Elementary-dev-community] How to review and merge branches
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 sufficiently simple to use), it makes no sense to avoid using it. On Apr 1, 2013 4:14 PM, David Gomes da...@elementaryos.org wrote: 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 webe...@gmail.com 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 so, for instance, other elementary developers aren't plagued by my style and I don't have to mentally manage a conversion between my work style, my personal style, and the styles of the various projects in which I participate. Yes we should review and test or own code, but we should know enough to leverage the accuracy and speed of software for frequent and mundane tasks like reformatting code. On Apr 1, 2013 1:11 PM, Victor victoredua...@gmail.com 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 webe...@gmail.com 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 da...@elementaryos.org 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 webe...@gmail.com 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 jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com 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 webe...@gmail.com 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 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 da...@elementaryos.org 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
Re: [Elementary-dev-community] How to review and merge branches
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, it's just that it's not an easy task. Also, let's please end the discussion on this thread please, we're really off-topic. On Mon, Apr 1, 2013 at 10:26 PM, Craig webe...@gmail.com wrote: 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 sufficiently simple to use), it makes no sense to avoid using it. On Apr 1, 2013 4:14 PM, David Gomes da...@elementaryos.org wrote: 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 webe...@gmail.com 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 so, for instance, other elementary developers aren't plagued by my style and I don't have to mentally manage a conversion between my work style, my personal style, and the styles of the various projects in which I participate. Yes we should review and test or own code, but we should know enough to leverage the accuracy and speed of software for frequent and mundane tasks like reformatting code. On Apr 1, 2013 1:11 PM, Victor victoredua...@gmail.com 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 webe...@gmail.com 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 da...@elementaryos.org 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 webe...@gmail.com 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 jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com 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 webe...@gmail.com 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 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
Re: [Elementary-dev-community] How to review and merge branches
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 da...@elementaryos.org wrote: 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, it's just that it's not an easy task. Also, let's please end the discussion on this thread please, we're really off-topic. On Mon, Apr 1, 2013 at 10:26 PM, Craig webe...@gmail.com wrote: 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 sufficiently simple to use), it makes no sense to avoid using it. On Apr 1, 2013 4:14 PM, David Gomes da...@elementaryos.org wrote: 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 webe...@gmail.com 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 so, for instance, other elementary developers aren't plagued by my style and I don't have to mentally manage a conversion between my work style, my personal style, and the styles of the various projects in which I participate. Yes we should review and test or own code, but we should know enough to leverage the accuracy and speed of software for frequent and mundane tasks like reformatting code. On Apr 1, 2013 1:11 PM, Victor victoredua...@gmail.com 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 webe...@gmail.com 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 da...@elementaryos.org 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 webe...@gmail.com 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 jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com 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 webe...@gmail.com 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
Re: [Elementary-dev-community] How to review and merge branches
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 da...@elementaryos.org 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 webe...@gmail.com 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 c...@elementaryos.org wrote: Cool, it's pretty thorough. On Wed, Mar 27, 2013 at 7:58 AM, David Gomes da...@elementaryos.orgwrote: 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] How to review and merge branches
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 da...@elementaryos.org 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 webe...@gmail.com 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 c...@elementaryos.org wrote: Cool, it's pretty thorough. On Wed, Mar 27, 2013 at 7:58 AM, David Gomes da...@elementaryos.orgwrote: 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] How to review and merge branches
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@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
