This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Bug Fixing Regarding .replaceFirst  RSS feed

 
Ariel Teague
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all!
I'm learning Java and working on strings, and I've come across something that's confusing me.
I was making a program to replace the first instance of "C++" with "Java." While I've tested it with other words with no problems, and the .replace works fine, whenever I try it with the C++, the word changes to "Java++" instead.
Any ideas on why this is happening and ways I can correct it?
Please find my attempt below.
 
Stephan van Hulst
Saloon Keeper
Posts: 7807
142
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ariel,

You should take a close look at the documentation for replaceFirst(), the first parameter doesn't mean what you think it means.
 
Ariel Teague
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks! That's where I was messing up.
Have a great day!
 
Liutauras Vilda
Marshal
Posts: 4640
316
BSD
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ariel, welcome to the Ranch.

Remark on slightly different topics.

Even tho your your IDE suggests you to close Scanner object, don't do that, because you may never open it again in case you need it, as it would close InputStream.
For the time being don't close it at all and just ignore that warning. For your own curiousity you can read about annotation @SuppressWarnings (that one should be used carefully).

Right from the beginning, try not to cram all your code into main method, but rather decompose it into smaller methods, even if those few lines of code are really simple and obvious.
So in that manner you could come up with something similar to, i.e.:

For your current program that way might would be an overkill a bit, but when the code gets bigger, it gives you a profit right away.
 
Ariel Teague
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Liutauras,

I'm still trying pretty new to Java, so would you mind explaining something regarding your comment? Is the primary benefit of separation readability? I was curious about how larger programs would look, but knowing I can split the program up into smaller methods makes that a little more obvious.

Thank you!
 
Liutauras Vilda
Marshal
Posts: 4640
316
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ariel Teague wrote:I'm still trying pretty new to Java
No worries, it is understandable
Ariel Teague wrote:Is the primary benefit of separation readability?
Not sure if it is a primary benefit, but it is one of the many benefits for sure.

Functionality
You are absolutely right, programs become more readable in that sense when you decompose it into smaller chunks of code and make methods out of them, where each method should be responsible for one and only one task. It is like a tool - "scissors" for instance. You know their purpose and you expect them to do that well.

Readability
Meaningful and self revealing method names play important role. If you feel that you cannot find the right word to describe what the method suppose to do, probably it does something wrong or too many things in one go. When someone says "scissors" you know instanty what is all about. The same way is a method name. When you read square(number) method should do what its name says - square number, no more or less.

Reusability
In case you need to do similar routine twice or more times, you don't need to repeat yourself, you re-use your written method as many times as you need it. Method should be flexible, so you could use it based on your new requirements. As an example could be Math.pow(). So it can square number, cubic, etc. So it is more flexible than mine:
Maintenance
Each method should be small enough so there wouldn't be a single place for programming errors to hide. You cannot fully avoid them, so when it happens, it simplifies debugging (finding errors) and later testing of your program. Try always to compile your program often enough, after you write every ~5 lines or so. In that case you can catch errors as early as possible, so it is easier to fix them, because if you know your code compiled 5 lines ago and suddenly stopped, you know that something went wrong in those 5 lines. The smaller method is, the easier to maintain it.

As you see there are benefits and I can't think of dissadvantages of it. So try to practice that, when you're not sure, post your code here, so the guys could have a look and advice you on that. For a start I'd say try to make methods out of anything, even tho if there are 3 lines of code. Keep one method named similar to run() I showed you earlier as an example, where the rest of the methods would be called, so they all would create a program flow.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!