1. As far as the methods you've created and are calling I see no problem with (as per your doubts). Functions calling functions is a good thing. Functions should pull all of their own weight, calling other functions when necessary, the coder shouldn't have to call those functions beforehand and pass in the parameters, unless of course there is a situation where you (the coder) do at times need to specify specific running values.

2. Your main looks good, however as far as aesthetics of your code goes, I would add spaces between your operators and symbols...

   //this
   cout<<"The largest prime factor is : "<<prime<<endl;
   
   //becomes
   cout << "The largest prime factor is : " << prime << endl;
   

   This lack of spacing is in other parts of the code, but I'm not going to point out everywhere.

3. Aesthetically this block of code could be re-factored a few different ways.

   //Use one liners and no ugly brackets.
   if(list.size() == 2) 
      return *(primeList.end());
   else
       primeList = computePrimeFactors(list);
   
   //Take advantage of the fact that you don't need an else after a return.
   if(list.size() == 2) 
       return *(primeList.end());
   primeList = computePrimeFactors(list);
   

4. Use shortcut operators

   n /= i;
   

5. Don't do extra work. There are two things to change about the code below.

   if(count == 2) {
       return true;
   } else {
       return false;
   }
   

   Kill the brackets as I did earlier. (opinion, and optional)

   if(count == 2)
       return true;
   else 
       return false;
   

   Now that we can see this code clearly, we can realize what it is actually doing. count == 2 yields a Boolean value which is then passed to the special if function, which then asks if the Boolean passed in was true, if so.. then return true, else false (oversimplification of what is happening on the low level, but you get the gist) count == 2 is a Boolean, so instead of using that in an if... just return the Boolean you got from using that operator.

   return count == 2;
   

This is absolutely fine. By calling only one function in main and letting it handle what it has been asked for, you are achieving the concept of abstraction, leaving out the unnecessary crunchy-details and just saying what you want, which is the largest prime factor of a given number. The user of this method does not need to know anything about how it works internally.

Abstraction is one of the key concepts of OOP, and since you are programming in C++, you'll start to see the benefits of using such patterns soon, when you start to use classes that can grow out bigger and more complex than expected. Then, you'll need to use encapsulation, which is achieved through abstraction. So, the earlier your adopt this kind of pattern, the easier it will be in the future for you to resolve other issues like these.

Now, regarding your code: one thing that I'd definitely do is drop these /* magic stuff happens here */ comments, which do more harm than good. They do not explain anything and just yell that this code probably smells. Also, you should pay more attention to your one-character-name variables, like n, which does not mean much and is hard (actually impossible, depending on the size of your code) to find through CTRLF if needed.

If you have access to C++11, you could also take a peek on it's features to improve your code. For example, loops such as

for(vector<llint>:: iterator i=factorList.begin();
                               i<factorList.end();
                               i++) {}

could become ranged-for loops

for(auto i: factorList) {}

Naming

What's the name of your function? "getLargestPrimeFactor"? So it must do all the work to solve the problem.

More generally, you want to make your code easy to use, and, if the user doesn't care about how it is done, providing one function with a correct name to do all the work is a welcome sight.

Customization

1. In one hand, you must provide a robust, bug-resistant, easy way for the user to get the result (here, the largest prime factor).
2. In the other, you could want to provide a way for the users to call the functions as it suits them. This should be optional, and this can be done different ways, depending on the type of customization you want to provide.

your priority is to provide the first part: A user should be able to easy have the expected result, the same way starting your car is just turning the key (or pressing the button).

If you really want to provide customization, then you must think carefully about the kind of customization you can, and thus, common idioms will apply.

For example, one naive solution would be to provide one class with all customization points being virtual methods. The users can then override the method they want to customize, while leaving the others as is. This needs research to find the right solution to your specific problem.

I think it's actually a really good habit to call functions from within functions. This is a very important concept in Object-Oriented Programming. If you wrote this source code using OOP, you might structure it like this...

• Class Main
  • main()
• Class PrimeFactors
  • public getLargestPrimeFactor()
  • private computeFactors()
  • private computePrimeFactors()
  • private isPrime()

As you can see, in this class any method called from Main is declared as public, and any method only called from within the class is declared as private.

Structuring this program as a class instead of a series of functions makes it easy to re-use the code. It makes Class PrimeFactors like a library that you can easily include into any main that you want.

I agree with the others about commenting less. I was reading Clean Code by Robert C. Martin the other day, and he argues that comments should be minimal and pragmatic. Ideally you want to choose very succinct names for your variables and functions/methods, and you want to make as many chunks of code into functions/methods as possible. And what this does is it names everything, which helps to avoid you needing to make as many comments in the first place. I think you're already on the right track with this because you wrote multiple functions and you tried to give them all good names.