> On Sept. 28, 2016, 9:54 a.m., Robert Levas wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertServiceStateListener.java,
> >  line 100
> > <https://reviews.apache.org/r/52345/diff/1/?file=1512284#file1512284line100>
> >
> >     Was adding `m_` a mistake, an old habit, or a new trend?  
> >     
> >     Personally I like the `m_` prefix, but most code in Ambari does not 
> > follow that convention.

When I create classes from scratch or work with classes which have their field 
names matching the method args, I always try to use `m_`. It's a throwback from 
my old Hungarian notation days. I'd love it if we used full Hungarian 
especially since Ambari loves to use Long/Integer/Boolean alonside 
long/int/boolean. Something like m_lVersionId tells you in the name that it's a 
field, non-static, and a primitive long. People argue that modern day IDEs 
alleviate the need for this, but we've had our fair share of NPEs casting Long 
to long and mistakes in losing scope of a variable in a large method.

Anywho, we'd never get consensus on it, so I never tried to get it officially 
added to our coding style wiki.


- Jonathan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52345/#review150714
-----------------------------------------------------------


On Sept. 28, 2016, 8:50 a.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52345/
> -----------------------------------------------------------
> 
> (Updated Sept. 28, 2016, 8:50 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Robert Levas.
> 
> 
> Bugs: AMBARI-18456
>     https://issues.apache.org/jira/browse/AMBARI-18456
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> Remove shared instances of the shared {{ReadWriteLock}} found in 
> {{ClusterImpl}}. For now, the lock can remain private and full encapsulated 
> inside of {{ClusterImpl}}, but it's use and reference across the rest of 
> Ambari should be removed.
> 
> This is part of the effort to refactor/remove the (mostly) unnecessary locks 
> in memory. The shared instance of this lock is the number one reason that 
> Ambari "deadlocks" when under load.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/annotations/ExperimentalFeature.java
>  1d5ba0e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  1fc9dbf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertServiceStateListener.java
>  da4cbf5 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java 
> 2452df6 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ConfigImpl.java 
> 7b7a60b 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Service.java 
> 7000574 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponent.java
>  983cbdf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentImpl.java
>  3e805a0 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java 
> 3120b86 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  2f7d6b9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/configgroup/ConfigGroupImpl.java
>  1d6b1e8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
>  3b5ed28 
>   
> ambari-server/src/test/java/org/apache/ambari/server/update/HostUpdateHelperTest.java
>  387205d 
> 
> Diff: https://reviews.apache.org/r/52345/diff/
> 
> 
> Testing
> -------
> 
> Tests run: 4679, Failures: 0, Errors: 0, Skipped: 35
> 
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 41:36 min
> [INFO] Finished at: 2016-09-27T14:21:22-04:00
> [INFO] Final Memory: 40M/739M
> [INFO] 
> ------------------------------------------------------------------------
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Reply via email to