Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialMenno Gouw
2,375 PointsWhy has been chosen for Hungarian notation?
I would appreciate a detailed explanation why you have chosen this naming convention and how it helps the coding in any way. Member fields are indicated by starting the name with a lower case (camelCase). Naming these properly would maintain readability, and I have always practiced to put readability at first place during development.
Here you can read a stackoverflow Q/A about it. https://stackoverflow.com/questions/2092098/why-do-most-fields-class-members-in-android-tutorial-start-with-m#_=_
I think it is much more important to teach us to document our code and keep classes small then to prefix field with specific characters.
package com.example;
import java.util.Date;
public class BlogPost {
private String author;
private String title;
private String body;
private String category;
private Date creationDate;
}
-edit- I was not aware this would be posted on the forums. So this might need some more explanation. My above code was rejected and the reason was that it's test expected my field to start with an 'm'. This is called Hungarian notation and I have a strong feeling that this is a bad habit of naming. Although I might be biased because I have never used it myself and rarely seen it. I know it's more common developing for android but this is a java course. I already start to get a headache if I need to name all my field like this in the next lessons, it sure isn't adding to the experience.
3 Answers
Steve Hunter
57,712 PointsHi there,
I think some of the older Java courses enforce the use of this notation - the later ones do not. It isn't a requirement across all the courses.
Steve.
Menno Gouw
2,375 PointsThats good news. I thought I was doing a "new" course anyway since the Java track contains a Lambda course too but I understand a track is just a collection of courses that fit together.
Steve Hunter
57,712 PointsYes, that's right - the track evolves constantly as new courses and workshops are added/created/updated. I can't see any way of seeing the release date of the course except by downloading the project files. The Java Data Structures download I just did shows a created date of 12th March 2015.
I'd recommend working your way through the track, adhering to the notation requirements but armed with the knowledge that such notation is no longer considered best practice.
Best of luck.
Steve.
Menno Gouw
2,375 PointsI will, but perhaps it's a good idea to consider updating the course since Java remains one of the most used programming languages. Some even claim Java is way on top of the list without any competition. It's the reason I'm doing this course to learn something new in a educational and properly structured way but I have several years experience with java from self teaching it.
Steve Hunter
57,712 PointsI am sure that all the courses are scheduled for review and update at certain intervals. The Treehouse guys need to balance the creation of new content with the curation of older courses that require update, with a finite amount of resource - a conundrum we are all familiar with! There may be a Trello board somewhere to request content & updates - I can only see the Android one but I suspect Craig Dennis will have a Java-specific one too.
Craig Dennis
Treehouse TeacherHi Menno we are in the process of breaking this course up into many and we will not be using Hungarian notation. These Java courses used to lead into the Android content where labelling member variables was the best practice.
In the Java Objects course (which was refreshed) I do discuss this too.