Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Proper code format with if/else

 
Sheriff
Posts: 15758
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This has certainly turned into a very interesting discussion. Reading through the different replies and perspectives, I see a familiar pattern. People who don't have much experience tend to focus on very low-level details. To the inexperienced, the details are what matters most to them. As people get more experience, the details become less of a concern. The focus starts moving to the more high-level and abstract. I think that's why Tim finds a mind map useful. That's also evident in Liu's suggestion to leave implementation details out of the notes and write about intent instead.

I think we all should recognize that OP is taking the kind of notes that he is taking precisely because he doesn't have enough experience to be able to focus on higher-level abstract ideas yet. He's not at a stage in his learning where his brain can whip out the nitty-gritty details almost reflexively like more experienced folks can. To him, what he's taking notes on is the hard stuff for him. For us, what we're suggesting to take notes on is the hard stuff for us.

The analogy would be trying to learn basketball, which I suck at. If I were trying to learn it, I'd probably focus on footwork, dribbling, basic body position when shooting. To someone like Michael Jordan or Lebron James, these things are instinctive. They've mastered this stuff. When they analyze their game, they focus on an entirely different level -- and the ideas at that level are so alien to me that I can't even put them into words because I can't (and probably could never) relate to that level of expertise in basketball.
 
Saloon Keeper
Posts: 22260
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unfortunately, while the low-level details may seem the most challenging, unless you have your high-level concepts sorted out first, it's nothing but trouble, as all of us who've been called on by people who prematurely "solved" a problem by picking a solution first and then found it difficult-to-impossible to realize know.

I'm a vocal critic of AYHTDI syndrome (All You Have To Do Is...), but that's because it's an over-simplified approach based solely on what people "know" the required effort is going to be. But if you don't start out at that level, you're basically going to end up running around in a maze. The key is that you have to work your way down like descending a pyramid, where each level gets more specific and more detailed. You cannot go from "Create capstone" to "create rest of pyramid", which is where AYHTDI fails. There are multiple levels that have to be descended one by one.

And yes, you can sort of hop-scotch over some of those levels with experience, but that's true of any vocation. In the beginning, alas, you really need to slog your way down. As the saying goes, you can't properly break the rules until uou know them.

edited because my typing was even wworse(sic!) than usual.
 
Junilu Lacar
Sheriff
Posts: 15758
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing about notes: we try to note down things we want to get right. There seems to be a strong tendency for notes to automatically turn into plans. That is, while notes suggest temporary scribblings, plans suggest more permanence and certainty. This, too, can be seen in the different examples mentioned. OP's notes translate directly to his code. For the more experienced folks, their notes translate directly to higher level designs.

With that said, I'll offer my way of organizing my thoughts. If you've hung around here long enough, you already know where this is headed.

Consider this idea of taking notes on paper (or virtual paper, as the case may be) -- that is, notes that aren't code-based, notes that are static. For me, this is what a whiteboard is for. I won't even mess around with an electronic form unless I really need to. When I do virtual development sessions, I share my video and show myself writing on a physical whiteboard. Anyway, my whiteboard "notes" are usually about very high-level ideas. They're mostly in picture form with maybe some text to call out important high-level entities, like module names or architectural layers, maybe a domain concept or two. On rare occasions, I might even draw a mindmap on the whiteboard.

My detailed "notes" are executable tests. Tests are the scratchpad that I use to tinker with ideas I know can change and be tweaked and experimented with. Tests are my playground and my IDE's refactoring features are my most important tools.

This might be a very foreign idea to OP and that's OK. But when you get to the stage in your learning where you are looking to write tests, I strongly encourage you to try using them the way I just described. Tests are much more valuable when used this way.
 
Junilu Lacar
Sheriff
Posts: 15758
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Unfortunately, while the low-level details may seem the most challenging, unless you have your high-level concepts sorted out first, it's nothing but trouble


That's probably the reason less experienced people get into trouble at the nitty-gritty level more often than more experienced people do. More experienced people get into trouble at another level of abstraction. Often times, that's worse trouble than the nitty-gritty kind because of the scale and scope of the mistakes that can be made.
 
Junilu Lacar
Sheriff
Posts: 15758
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My point, if I haven't made it clear yet, is that we focus on things that are appropriate commensurate to our level of expertise. To expect an inexperienced person to be up to the task of thinking about high-level abstractions that's outside the realm of their experience is probably too much. I'm not saying they won't ever get there because certainly with time and practice, they'll get better, but at this point, I think that would be like asking a third-grade level student to solve a quadratic equation. They're just not there yet.
 
Ranch Foreman
Posts: 89
5
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, I can see the err of my ways. When I am describing an issue or process, I am seeing it from the eyes of me...the coder...not the user.  Then trying to determine the different steps that I am going to have to hoop through in order to achieve my end goal is where my note taking comes in to play.  This is what I was trying to convey.  What it seems as though when I am going to describe an app in the future that I should describe it from the eyes of a user who knows nothing about a main method,Main class or a boolean.

Liutauras and Campbell thank you for your feedback. Yall go make a programmer out of me sooner or later! ...and I've got to get me some of those crazy face emojis for times like this.  
 
Junilu Lacar
Sheriff
Posts: 15758
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:Ok, I can see the err of my ways. When I am describing an issue or process, I am seeing it from the eyes of me...the coder...not the user.  Then trying to determine the different steps that I am going to have to hoop through in order to achieve my end goal is where my note taking comes in to play.  This is what I was trying to convey.  What it seems as though when I am going to describe an app in the future that I should describe it from the eyes of a user who knows nothing about a main method,Main class or a boolean.


There is no ONE way to develop software. Certainly, there are patterns and strategies and some patterns/strategies may work better for you than others. Over time, that too will change. The different perspectives you mentioned are not mutually exclusive. It just depends on the context. If you're trying to communicate with people who need to understand what you're trying to do, sure, speak from the user perspective. Even from a coder perspective, it's useful to communicate in terms of intent rather than implementation. However, this doesn't mean that there's no place for an implementation-focused conversation either.

The point is, know your audience, know your intent. Then choose your perspective and frame the conversation accordingly.
 
Marshal
Posts: 69790
277
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:. . . . Yall go make a programmer out of me sooner or later! . . . .

Don't worry; we shall
 
bryant rob
Ranch Foreman
Posts: 89
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:That's also evident in Liu's suggestion to leave implementation details out of the notes and write about intent instead.



I can't believe I missed this earlier but my issue is the line between implementation and intent is blurred.  I currently see both as one.  Hopefully the more I code the more I will learn to recognize them as separate parts to the solution.
 
Campbell Ritchie
Marshal
Posts: 69790
277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IntentIntent and implementation detailsDo you know what Bédzryczowki's algorithm is? Or is it something I made up to write about? The following provides more details:-Remembering that Warsaw was a hotbed of mathematical genius in the 1930s, but what if you can't read Polish?That condemns you to use the same algorithm for ever. II shall let you wok out what to write al allow you to change the algorithm if something better is developed.
 
Junilu Lacar
Sheriff
Posts: 15758
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:my issue is the line between implementation and intent is blurred.  I currently see both as one.


It's really as simple as saying "Get the sum two numbers" (intent) vs. "Assign a + b to the variable sum" (implementation)

Another way to think about it is to ask "If I put all that functionality in a method, what would I name the method?" The name you come up with should describe the intent succinctly, e.g. sum(). The implementation is the code inside the method that answers the question "How?"
 
bryant rob
Ranch Foreman
Posts: 89
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Junilu that is pretty simple.  Intent over implementation it is.
 
Sheriff
Posts: 7646
522
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:Intent over implementation it is.


The idea of it is, so you wouldn't get stuck on nitty gritty details at an early stage while you actually solving a problem. Such low level detail things you can decide later when it is really necessary.

Let's take an example:
1. "Looking for an item, it tells at which position it was found, or states it wasn't found otherwise"

2. "searchItem() returns an index position of String item..."

So, in the former example we get a high level idea how that will work without getting into coding ceremony. For instance, if item not found we have couple of options, we may want to return -1, or we may want to throw an exception - we can decide later, when we get to implementation part and when we have a better picture.

In the latter example you are really kicked into the corner with already prescribed coding solution, which you'd find more often than not it differs from your initially thought. To come up with a good method name it may take time, and you might even rename it several times afterwards, In which case your notes would be off, while former notes still hold a correct high level logic and that all it matters, because two developers potentially would always solve the same problem differently from the implementation standpoint, while at the high level they would still attack the exact same problem.

Codings style notes are really code, so it is less beneficial to write them twice, while high level notes help you to stay on the problem line and don't drift from the solution.
 
bryant rob
Ranch Foreman
Posts: 89
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:

bryant rob wrote:Intent over implementation it is.


The idea of it is, so you wouldn't get stuck on nitty gritty details at an early stage while you actually solving a problem. Such low level detail things you can decide later when it is really necessary.



You are absolutely correct here. I forget who stated it on this forum, as I am sure it has been stated numerous times as well but as a beginner I am in such a hurry to code that I rush out of the planning phase into the coding phase before it is time. While something so simple as this grocery list app can be, I have come to realize that thinking in the abstract first, noting my intent and not focusing so much on implementation would have simplified the steps to successfully writing this code.



 
Campbell Ritchie
Marshal
Posts: 69790
277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:. . . I am in such a hurry to code that I rush out of the planning phase into the coding phase before it is time. . . .

That sounds like Winston Gutkowski.
 
bryant rob
Ranch Foreman
Posts: 89
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:That sounds like Winston Gutkowski.



With every post you all make with regard to my posts I try and become better...isn't that the point after all? After reading your link the other day to Winston Gutkowski  I realized that I do want to jump in and start coding, and that link kind of hit home for me. I even went back and rewrote the code for my grocery list whereby when the user wants to search for an item by item name to either remove that item, or modify the list somehow, there is a separate method that is called to search to make sure the item is present in the list, and that method is now private, and called by the remove and modify methods. So  essentially one method doing the searching and the other methods doing the removing and modifying instead of each of those methods performing their intended purpose as well searching too. I figure in the real world a user might need to search for an item for some other purpose other than removing an item or modifying an item or the list itself, and so that method needed to be created.

My point in stating this is that at one point I would have stopped after achieving the results I was looking for because hey, I got the code to do what I wanted it to do.  But with a little planning and abstract thinking I can see, whether or not I will take the time to to do this every time, a better way of writing the code so as to be able to include both static and instance methods, as well as both private and public access modifiers.
 
Wink, wink, nudge, nudge, say no more, it's a tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic