8:01 p.m.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the project
refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to read
code that is not in this style. Hence I can understand why people may object to changing
their style. However, this is the very reason why a common style is beneficial. You can
get used to a new style and once you do, the entire project will be styled in the way that
you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes making
their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:01 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
One problem with this is that it will be hard to do diffs between code versions before and
after the formatting. This could make tracking down bugs significantly harder.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:21 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
However, I think most of the code formatting changes will consist of white space
manipulation. Therefore we may be an option to do a diff ignoring white space.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:01 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson commented on JBTM-989:
------------------------------------
Its a small step, but I have organized the imports, so at least you can do an IDE
ctrl-shift-o (I think that is it), even if not a ctrl-a ctrl-shift-f
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:40 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson commented on JBTM-989:
------------------------------------
My recommendation is that new/peripheral code should be the first target for this,
component owners should be able to decide whether a code path is "peripheral"
enough to be considered for code format.
I think we should adopt the JBossAS code style, if you grep the README.md from
https://github.com/jbossas/jboss-as and check for "Using Eclipse" it mentions
how to configure eclipse code styles by importing some templates from:
https://github.com/jbossas/jboss-as/tree/master/ide-configs. IDE configs are provided for
IntelliJ, Eclipse and Netbeans.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:24 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Michael Musgrove commented on JBTM-989:
---------------------------------------
There isn't codestyle template for IntelliJ (the thing you refer to is for
inspections). The code I write for AS generally passes their checkstyle goal so maybe I
can carry on writing code the way I have always done. Or perhaps there is a doc somewhere
that I can scan for any gottchas.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:28 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
I've found the default Intellij code style passes the AS7 checks. This is lucky as I
can't find a way of importing/exporting the codestyle.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:38 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
I suggest we take some example classes, format them and see how easy it is to do a
white-space ignoring diff.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:02 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson commented on JBTM-989:
------------------------------------
git diff -w
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:56 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Mark Little commented on JBTM-989:
----------------------------------
Playing Devil's Advocate: and what happens to certain modules that are only every
touched by one person who may not like the specific code style?
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:34 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
{quote}
Playing Devil's Advocate: and what happens to certain modules that are only every
touched by one person who may not like the specific code style?
{quote}
This causes problems as you can't put checks in the build process to prevent
rogue-formatted code from being committed. It also makes it harder, should another
developer need to work on this module as they need to ensure they don't apply the
common code format.
I don't personally like the AS7 code format, but I have to use it when i work on the
AS7 codebase. However, I'd be happy to get used to it if we get the benefits of a
common style in Narayana.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:36 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
Also, I think it's worth stressing that the reason why this is being suggested is not
because I/we don't like the current code style. It's because using a common
code-style brings efficiencies. Hence the reason why I'm willing to adopt a style that
I don't like.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:36 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson commented on JBTM-989:
------------------------------------
I think this should apply to all modules hanging off the root narayana pom. The following
statements should be taken assuming we do decide to reformat:
I don't think we have any modules that fulfil the property of being isolated to the
single developer degree, some could be at the moment but in the long term are very
unlikely to be. Incubator style modules - e.g. STM - where there is a single developer
working on it at the moment, probably don't need the formatting *right now*, but
before they become .Final and as such become community supported I believe they would need
to follow the consistent style as the developer has contributed that work to the public
domain and adhering to a formatting will make it easier for other developers to then
submit patches/pull reqs.
Also, a note to the above statement, if we don't like the AS7 style potentially we
could develop our own (negating one positive which would is consistency with AS7). I am of
the opinion of where I don't really mind what the code looks like (within reason) so
long as it all looks the same?
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:40 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-989:
------------------------------------
{quote}
Also, a note to the above statement, if we don't like the AS7 style potentially we
could develop our own (negating one positive which would is consistency with AS7). I am of
the opinion of where I don't really mind what the code looks like (within reason) so
long as it all looks the same?
{quote}
There's nothing wrong with the AS7 style (IMO). I am the one with the problem as I am
not familiar with that codestyle. I'm sure that over time I would get used the the AS7
style and no longer like my current style.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:35 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson commented on JBTM-989:
------------------------------------
I think we should park this for now as there isn't sufficient argument to make the
change.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:23 a.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson resolved JBTM-989.
--------------------------------
Resolution: Deferred
Deferring till we get a killer argument for this feature
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:12 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Michael Musgrove edited comment on JBTM-989 at 4/5/12 2:11 PM:
---------------------------------------------------------------
There isn't codestyle template for IntelliJ (the thing you refer to is for
inspections). The code I write for AS generally passes their checkstyle goal so maybe I
can carry on writing code the way I have always done. Or perhaps there is a doc somewhere
that I can scan for any gottchas.
But there is a plugin that allows using Eclipse's code formatter directly from
IntelliJ. Look for Eclipse Code Formatter in File -> Settings -> Plugins
The documentation at http://plugins.intellij.net/plugin/?idea&id=6546
was (Author: mmusgrov):
There isn't codestyle template for IntelliJ (the thing you refer to is for
inspections). The code I write for AS generally passes their checkstyle goal so maybe I
can carry on writing code the way I have always done. Or perhaps there is a doc somewhere
that I can scan for any gottchas.
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:47 p.m.
[
https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.s...
]
Tom Jenkinson updated JBTM-989:
-------------------------------
Fix Version/s: 4.17.0
(was: 5.0.0.M2)
Consider using a common code style throughout Narayana
------------------------------------------------------
Key: JBTM-989
URL: https://issues.jboss.org/browse/JBTM-989
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 4.17.0
I think we should consider using a common code style throughout the TS project. The
benefits of doing this are as follows:
# You can automate code formatting. This is a real productivity boost as you can type
away, thinking about your code, rather than the style. When you hit save, or trigger it
directly, the code is formatted.
## This is not possible without a project wide code style as you too frequently re-format
code that needs to stay in someone else's personal style. You can't commit this
changed code as; a) it may annoy the "owner" and b) it results in a change that
can't be diffed (every line may be changed).
# We get consistency over the whole project, making it easier to read code written by
others.
# We have to do this anyway for code we maintain inside the JBossAS project as the
project refuses to build if it doesn't adhere to their style.
Personally, I like the style I've used for the last 10 years. I find it harder to
read code that is not in this style. Hence I can understand why people may object to
changing their style. However, this is the very reason why a common style is beneficial.
You can get used to a new style and once you do, the entire project will be styled in the
way that you are used to. Providing the style is sensible, I would much rather use a style
consistent across the projects I work on. I'm happy for that style to be different to
my current style.
As I stated above JBossAS mandates a style at build time. I don't particularly like
the style (braces should occupy their own line, IMO) but I'm happy to go with this one
if it becomes the Narayana standard style.
I think we should also break the build for violations. This should prevent mistakes
making their way into SVN.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4452
days inactive
4785
days old
jbossts-issues@lists.jboss.org
17 comments
6 participants
participants (6)
-
Mark Little (JIRA) -
Michael Musgrove (JIRA)
-
Paul Robinson (Commented) (JIRA)
-
Paul Robinson (Created) (JIRA)
-
Paul Robinson (JIRA)
-
Tom Jenkinson (JIRA)