Ending my Palindrome Code Properly

[Kevin Thien]

import java.util.*;
public class Palindrome
{       
    public static void main(String[] args)
    {   
        new Palindrome();  
    }
    
    public Palindrome()
    {   
        String palindrome = "";
        while (!end(palindrome))
        {
            palindrome = readString();
            showPalindrome(palindrome);
        }
    }
    
    public String readString()
    {
        System.out.print("String: ");
        return In.nextLine();
    }
    
    public void showPalindrome(String s)
    {   
        if (isPalindrome(s))
            System.out.println("    yes");
        else
            System.out.println("    no");   
        }
    
    public boolean isPalindrome(String text)
    {   
        return text.equals(new StringBuffer().append(text).reverse().toString());   
    }
    
    public boolean end (String endString)
    {
        if ("end".equals(endString))
        {
            return true;
        }
        return false;
    }
    
}

Currently the code works perfectly fine in telling me whether an entered string is a palindrome or not, however, when I use my sentinel-string "end", the program will end but it will print out "no" which isn't really needed. I'm sure I'm missing something super simple but I can't figure it out for the life of me (yet).

[Rameshwar Soni]

Howdy Kevin !!! Welcome to Ranch

Firstly when i executed your code i got an error for variable "In" which you have on line number 22. So i think you can correct that with declaring a Scanner class Object "In" before using the nextLine() method. i.e.

 Scanner In =new Scanner (System.in);
  In.nextLine();

Now your main question that when i enter the String "end" the program still prints "no". So ONE WAY of solving this which i tried is to write an extra "if-statement" in showPalindrome(String s) method. Since you already have written the code which shows your effort, i will directly show what i had written to solve the problem

public void showPalindrome(String s)
    {   
	if (s.equals("end"));
		
        else if (isPalindrome(s))

             System.out.println("    yes");
        else

            System.out.println("    no");   
      }
 

You can see the extra if-statement there, note that there's an semi-colon too at the end of if-statement.

Also note there will be many other good ways of solving this, but this is what came in my mind. Thanks.......

[Kevin Thien]

Ah yeah, I had that idea too, but I was hoping for a "cleaner" way to do it I guess without an extra IF statement. The IN class is within my package so that's okay, thanks for the answer though!

[Winston Gutkowski]

Kevin Thien wrote:Ah yeah, I had that idea too, but I was hoping for a "cleaner" way to do it I guess without an extra IF statement. The IN class is within my package so that's okay, thanks for the answer though!

Actually, you can. You just need to turn your loop around a bit, viz:

String palindrome = readString();
while (!end(palindrome)) {
   showPalindrome(palindrome);
   palindrome = readString();
}

You can even shorten it a bit more:

String palindrome;
while ( !end(palindrome = readString()) ) {
   showPalindrome(palindrome);
}

I have slight preference for the first, but either will do the job.

A couple of other points:
1. You're better off using StringBuilder, rather than StringBuffer. The API is identical.
2. I notice you're familiar with the "end".equals(endString) idiom. Well you can also use it in your isPalindrome() method as well:
return new StringBuffer().append(text).reverse().toString().equals(text);

HIH

Winston

[Edit] Just thought of another possibility for your loop:

for (String s = readString(); !end(s); s = readString()) {
   showPalindrome(s);
}

which will keep the 'minimal scope' police happy.

[Junilu Lacar]

To make your code even less superflous, StringBuilder has a constructor that takes a String used to initialize the StringBuilder, so you don't have to call append().

Also,

// This is redundant
if ("end".equals(endString) {
    return true;
} else {
    return false;
}

// all you need is the boolean expression
return "end".equals(endString);

Some of your variable and method names could be better. 'palindrome' and 'endString' are not very good name choices. 'palindrome' is not the palindrome yet, it's the original string, the user input. 'endString' is not really the endString either, it's still the user input that may or may not be the end sentinel value. And since 'endString' is already declared as String, it's redundant to have 'String' in the name. It's like your parents naming you 'KevinBoy' instead of just 'Kevin'. The "Don't Repeat Yourself" (DRY) principle applies to variable names as well. And the class name 'Palindrome', I would call it 'PalindromeChecker' instead but that's not a real biggie.

Give names that help reveal and clarify the intent of your code; read your code and sniff out the names that can be misleading. This will make your code more understandable and can help you write fewer bugs. I tell folks when I review code: "Your code should tell a story. That's why we have the @author tag on the JavaDoc. If the code you write isn't telling the story well because you use the wrong words, your code sucks just as any poorly written story sucks."

// the '!' is a little hard to spot here
while (!end(userInput)) { ...  
}

// I prefer to spell out 'not' in the method name...
while (notEnd(userInput)) { ...

private boolean notEnd(String input) {
     // ... and hide that '!' in here
     return ! "end".equals(input);  
}

// finally, this tells the story a lot better, IMO:
return reverseOf(text).equals(text);

The implementation of the reverseOf() method is left to you as an exercise; you've already been given everything you need. It might be a fun challenge to see if you can implement some logic for checking for imperfect palindromes.

One more thing: always try to separate display concerns from other concerns. showPalindrome() does two things: checks if a string is a palindrome and displays "yes" or "no". You actually don't need the showPalindrome() method.

[Aditya Jha]

Please note that if this question is part of an academic exercise, they probably want you to check palindrome without using an API like StringBuffer.reverse().

[Junilu Lacar]

Aditya Jha wrote:Please note that if this question is part of an academic exercise, they probably want you to check palindrome without using an API like StringBuffer.reverse().

This may or may not be true, depending on what the goal of the exercise is and the quality of instructor. IMO, if the instructor didn't want the students to use built-in functions like reverse() to check for a palindrome, then this is the wrong problem to give the students. There are better ways to illustrate the proper way to apply iteration over arrays.

One thing that bothers me when I see problems where students have to resort to "clever" tricks is that this is not how it works in the real world of professional programming. We need to strive for the utmost simplicity and straightforwardness in our code. The problems that we try to solve are complex and complicated as it is without code that's hard to understand. If something has already been done before, don't try to reinvent it or reimplement it yourself. Use all the tools you have at your disposal to achieve your goals. The Director of Agile Practices at Intel likes to say "Steal with pride," that is, there's no shame in using somebody else's code if it helps you get the job done better and faster (barring any licensing issues, of course).

By teaching students in ways where they have to find hacks and "tricks", instructors are only doing them a disservice by giving them the wrong ideas of what programming is really about.

[Rameshwar Soni]

@Junilu Lacar ---- 100% agree with you. But the case is same in our University too, the professors tell us not to use in-built methods for such programs like palindrome, armstrong number etc. They say you write your own logic this will help you in building and developing programs. But we friends discuss among ourself that what's the use when we have in-built methods and this is what we are going to use in REAL WORLD.

But these professors don't understand that there are many many more things to understand apart from these already available logic. But there's nothing we can do.

[Winston Gutkowski]

Junilu Lacar wrote:To make your code even less superflous, StringBuilder has a constructor that takes a String used to initialize the StringBuilder, so you don't have to call append().

That occurred to me too; but then Kevin wouldn't be able to use the "inverted" comparison idiom, because that constructor throws NPE if text is null.

Agree with everything else you said though.

Winston

[Winston Gutkowski]

Junilu Lacar wrote:The Director of Agile Practices at Intel likes to say "Steal with pride," that is, there's no shame in using somebody else's code if it helps you get the job done better and faster (barring any licensing issues, of course)...

The only thing I would add is that, where possible, you should attribute plagiarised code - especially if you're doing it as part of a school or university course - but to me, it's just plain good manners. Better still, don't plagiarise it; use it.

"Imitation is the sincerest form of flattery" - Marcus Aurelius

Winston

[Kevin Thien]

Wow, thanks for all the responses guys, learnt a lot! While this was academic, we were allowed free-roam so to say as to how the actual palindrome check worked. So we could've done it via array, or reverse. I just found it easier to code the reverse method because it was a single line of code.

[Winston Gutkowski]

Kevin Thien wrote:I just found it easier to code the reverse method because it was a single line of code.

And that's just fine. In fact, in the real world, you almost always want to find an existing method/class.

Fancy writing a linear-congruential generator? Nah: use java.util.Random. It was written by a team of experts who've probably forgotten more about random numbers than you or I will ever know.

Don't re-invent the wheel. It may be trite, but its true.

Winston

[Kevin Thien]

Winston Gutkowski wrote:

Kevin Thien wrote:I just found it easier to code the reverse method because it was a single line of code.

Don't re-invent the wheel. It may be trite, but its true.

Winston

Yup, that's what our teacher says too. If it already exists, use it. No point in writing complicated lines of code if a single method can do everything for you!

[Aditya Jha]

I have a slightly different point of view.

When programming is learnt as part of an academic course, it is required that the concepts (say, data structures) are explained and are covered by a series of programming questions which help in demonstrating whether a student has indeed grasped the fundamentals or not.

Testing a string for palindrome in real world should definitely be achieved by using library functions, because there are bigger problems to solve. However, an academic exercise of the same problem must have been presented to students so they can demonstrate their grasp on a related concept (for example, using arrays or Stack). Here, the concept being explained takes precedence, and not the problem itself. And it's always good to wrap the concepts in a puzzle of sorts which (a) you can relate to, in a layman's way (without necessarily being reminded about the concept in question), and (b) can test whether for an apt problem, if you can figure out how to use the concept or not.

For example, how would you solve the same problem using (a) arrays (b) Stack or (c) None of these. All 3 are valid questions and simply testing the approach you would take to solve this puzzle. It's the approach which is relevant in such an academic exercise, not the puzzle itself. In fact, another perfectly valid question would be how would you solve this same problem by using a library function, IF the topic being taught is "Common classes and methods in Java".

It wouldn't be wrong to say that you will get more marks if you have the correct approach, even if for some small reason you're still not able to solve the given problem, as opposed to you solving the given problem with a wrong approach, which does not use the concept being taught.

[Rameshwar Soni]

@Aditya-------- I definitely respect your point of view, since everyone has their own way of thinking.

But i disagree with you because there's no point in wasting time to solve such problems if they can be solved by using an in-built method. This is why 95% graduates are not suitable for REAL WORLD programming which we use in industries

I think it's high time to teach students how things happen in real world.

[Winston Gutkowski]

Rameshwar Soni wrote:This is why 95% graduates are not suitable for REAL WORLD programming which we use in industries

Actually, I think you're both right. Students shouldn't be dissuaded from using existing clasees if the rules allow; however, allowing them to use them all the time is likely to breed a generation of programmers who don't recognise patterns in design. Rather like the cashier at my supermarket who will calmly charge me 50 quid for a single steak and a pint of milk because he doesn't even realise that he's made a decimal point error, because he's only ever used a calculator for adding.

I think all programmers should be required to write at least one divide-and-conquer sort in their lives and create a few different types of hashtable from scratch; what I don't expect (and would probably mark them down for) is for them to do it when they're writing a project.

Winston

[Aditya Jha]

@Rameshwar

I firmly believe, it is NOT the problem which is of relevance here, it is the concept that they are trying to teach.

If I'm teaching Stacks to students, I would not give them "Guessing next move on a Chess board" as the first problem. I would give something similar to palindrome, so they don't have to spend time in actually figuring out the business-logic, and can focus on the technical solution using a Stack, for the time-being. A bit later, I can always introduce some worthwhile problems, which also test their analytical abilities.

There is a reason why when you give interviews to the likes of Google, Amazon etc., they want you to be able to come out with Dijkstra's Algorithm on a graph, or even Depth-first traversal on a Tree without recursion, right there in the interview on a white-board. They always wrap the problem in a nice problem-statement, which will not give you an idea about what they actually want to check. Again, it's not the solution they look for (which could arguably be achieved with some brilliant libraries) but the approach.

It's all very good that students should be taught about real world problems. However, I don't think presenting them with a real-world project on the day they learnt arrays is a good idea. You would rather take baby steps with them, make sure they understand the nuances of the data-structure in question, and in the process, prepare them for the eventual "big" real-world problems.

As for real-world problems, if I were to check palindrome for a million strings in a limited-resources context, I would find another way than instantiating a StringBuilder for each string. It's always good to have practised programming concepts in their most basic forms.

[Aditya Jha]

Winston Gutkowski wrote:I think all programmers should be required to write at least one divide-and-conquer sort in their lives and create a few different types of hashtable from scratch; what I don't expect (and would probably mark them down for) is for them to do it when they're writing a project.

This is what I believe.

[Junilu Lacar]

You're both right, from your respective perspectives. Maybe you missed my statement that this problem or at least the way it is framed is not appropriate to teach the concept of iterating over arrays. If the instructor had wanted to know if the students understood the concept of iterating over arrays, then give them an array of characters or include specific instructions to convert the input text to a character array and iterate over it to get the reverse of the input text. However, giving the students free rein to implement a solution as they want should result in a simple and straightforward solution that uses all available tools at their disposal. It goes back to the quality of instruction and the proper framing of the problem in the context of the teaching goal.

[Junilu Lacar]

Bhanuprasad saketi,
Your post was moved to a new topic.

[Campbell Ritchie]

Winston Gutkowski wrote: . . . cashier at my supermarket who will calmly charge me 50 quid for a single steak and a pint of milk . . .

You obviously only shop at *****

I agree. Students ought to write their own stacks, linked lists, trees and arrayed lists. They need to know how they work, so they will understand which to choose in real life. A graduate needs to understand what the program is doing, and that is what you pay them for. Not for being able to churn out code.
They should never write their own for a real‑life project.

[Winston Gutkowski]

Campbell Ritchie wrote:You obviously only shop at *****

Yes, unfortunately had to close the Fortnam's account after I lost the yacht.

Winston

[Campbell Ritchie]

I was wondering where you could still buy a pint of milk.