- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Wonder what the frist backup is named.
Admin
TRWTF is listening to a Rails developer's advice.
Admin
Indeed. Obviously, a Rails developer's advice must be discarded purely on the premise that they are a Rails developer. Whether or not they actually have a point, is irrelevant.
Admin
Speaking of GIT commit, if you're ever stuck with what to write, this link gives you many great suggestions to choose from!: http://whatthecommit.com/
Admin
...though in this case I think what they have is an excuse to be undisciplined rather than a point. Here I am in the editor and now I have to roll through the commit history to understand the motivation for the code I'm looking at? Not if I can help it.
Admin
I've been at quite a few places that were in the mindset of "self-documenting code", i.e. you don't need comments because it should be clear what your code does. While I agree to a point, I feel comments are useful when they outline an algorithm or a section of code that might not be apparent what is going on, or to add clarification to why something is done the way it is.
Admin
"I ended up examining some board games with Richard Stallman"
Any recommendations Remy?
Admin
Maybe it was having a mentor at my first job who was 110% in love with unit tests in python, or the near complete absence of automated testing at my current job, but I love writing tests. It makes things right with the universe and makes fixing bugs 80% easier.
Admin
Big fan of having a hierarchy of information.
With good tooling all of these are integrated [right into the IDE] for the code.
Admin
It's not that black and white.
His point is that a commit message and the code that was committed are linked to the same point in time. And that has its advantages. It's a good point.
Your tooling apparently doesn't work nicely with that workflow, so for you, that doesn't work. Surely yours is not the only tooling that doesn't work nicely with this workflow, so it may not be the correct workflow for many people. That's a good point, too.
Vim in combination with some awesome plugins by Tim Pope can make it trivial to grab the commit message that accompanies a certain line of code. Similarly, newer editions of Visual Studio make it trivial to get the commit(s) that changed a method or class. So with this tooling, the workflow might work just fine. I wouldn't know, I haven't tried.
Again, it's not that black and white. There's no silver bullet.
Admin
Addendum:
And MY point was that it's a bad idea to dismiss an idea simply because it's coming from a Rails developer. I don't care if the guy actually has a point or not.
Admin
Remy says:
I'll may need to think on this for awhile....
Admin
Well, the game we were puzzling over was Bambolo, which is what happens when Germans reinvent Jenga. It's interesting, but I'm not huge on dexterity games. Also, it makes a huge mess.
I am a fan of social games, so I enjoyed playing a few rounds of Spyfall. I'm also big on co-op, so if you're looking for a more general game recommendation, I'm big into Arkham Horror.
Admin
The rails developer does have a point within reason. Cluttering code with comments is really annoying.
Actually the point really does go beyond the specific programming language and into the position of the language experts. Knuth was around more at a time where fluency and literacy in programming was uncommon.
Put it this way, lets say I can read German natively. Then a line of English for each line of German is going to be redundant and actually very annoying. The solution to this these days tends to be self documenting code but even then there are things that you really want to explain such as deeper overall meanings. Self documenting code is actually code that is simply organised sufficiently with goot meaningful words or phrases used for identifiers giving the best of both worlds. Such code needs less explanation, is quicker to read as it leverages both fluent English and code reading skill, etc. This means things like avoiding mnenomics.
Comments in modern programming where rosetta comments more often than not get in the way tend to be functional. For example, a warning that a line of code might have side effects or problems in certain cases. Comments can also be used to extend the language in various ways. Where comments do explain things, it might be pitfalls or things that are not obvious up front.
Because comments get in the way of the actual code people are trying to read and work on, you have to be careful not to be too gratuitous. Commit messages are a location where you can get away with being more gratuitous.
The point is that over time, things have changed and in terms of how we look at a language directly, Knuths approaches are less generally applicable and now more restricted to certain scopes such as academia or where you are transcribing expert knowledge, need expert verification of an algorithm, very complicated algorithms, etc.
Admin
Game links:
http://www.boardgamegeek.com/boardgame/293/bamboleo
http://www.boardgamegeek.com/boardgame/166384/spyfall
http://www.boardgamegeek.com/boardgame/15987/arkham-horror
Admin
The point about "why" versus "what" or "how" is best shown by a line of code and some potential comments:
i++;A comment that says "add one to i" doesn't add to the information provided by the code itself, especially when it is left alone and the code is changed to
--j;(I'd argue that this part is specious; see below)A comment that says "advance to the next element" tells us why we are adding one to i (something the code itself doesn't do), and might remain true when the code is changed as above. (That "might" is why the part above is specious. If it doesn't remain true, the comment is just as wrong as the one above becomes...)
A comment that says "fix bug 5427" is of no use at all.
Putting "why" information in the commit log isn't right either, because it isn't there when I look at the code. I must look for it elsewhere, and even if the IDE (etc.) makes that easy, it's an extra step, and the commit log doesn't explain why that line is like that in a 30-line insertion.
Admin
Comments. Comments! We all write comments. The problem is that they need to be useful. I take the stance that you need to write comments to yourself, because the "you" six months from now will likely NOT understand all that you did when you wrote the code.
So, write comments to explain the code to the 6 months in the future you, because you will hardly recognize the code then, and if it is any longer, the magic is gone, and your brilliance will have faded away, long long ago.
Admin
If you can't write useful comments, you should not be coding. At least, you should not be coding anything which someone else might need to work on.
If you can't write a sensible test suite, how the hell did you debug the code? Oh, you ran it once and it didn't crash? Good - don't let the door hit you on the way out.
The only code that should reach integration is clearly written, documented, and tested code.
Amateurs and hackers not welcome.
Admin
<quote>Put it this way, lets say I can read German natively. Then a line of English for each line of German is going to be redundant and actually very annoying. </quote>
Let's run that analogy a little further. Suppose every english line is displayed in a different, soft color. Your eyes now can tune them out and ignore them completely, until you get to the actual part where you're having trouble reading german, which is when you'll want the extra information that you can get in that english line.
Congratulations! Your point was just unmade by the ONE feature that is guaranteed to be present in even the crappiest IDEs for the crappiest languages. (Except Whitespace)
PS: I hope this forum's current software allows for us to insert our own tags.
Admin
Pervasive comments are guaranteed to drift from reality like a drug addict. So non-doxygen comments need to be sparse at most, and should speak from a higher level. Particularly interesting or tricky bits deserve comments. Very little code should be of such ilk though. If a significant amount is, it most surely sucks. It needs to be broken up a bit better, or it suffers from an architectural WTF altogether.
There's an unspoken notion that if one writes hand-holder comments about every line or change, another can then work on/with it, and skip the part where he actually reads and grasps the content before he gets any bright ideas.
It's nothing but a cop-out. Competent devs don't need or want it. The only ones who have ever complained about my lack of logorrhea have been dumb scriptkids. The last lamer is overly verbose in both speech and text. It's no surprise, as she needs everything spelled out for her, and still efficiently deflects most information.
This example is a WTF mini-article in itself: she stepped through some code, not mine: Enqueue(...); Wait(...); She actually concluded out loud that Wait() does the actual work. When she stepped through it again, the action occurred between the two calls. She almost jumped out of her chair as she looked at us all befuddled.
Easy Reader Version: Heavy comments are for crappy code and crappy coders. Lose both.
Admin
Not from me, but: Programming is the art of telling another programmer what you want the computer to do.
Admin
The reason for this comment is to explain to the future me, after 6 months, what the reason for this comment was.
Admin
Sure, highlighting, code folding, extra provide an assist but that's all they do. They do not eliminate the problem entirely. Your eyes still have to move more, it may be harder to register but your visual system still has to process and filter out the noise even if it is assisted, there is still more noise, if you do certain things like hotkey duplicate a line and move it up then it must be moved up more and may bring about havok if you have folder comments in the path, search or find in file is going to pick things up in the comments, you need to also maintain the comments when you maintain the code, etc. By just colouring them out even if your visual system can filter them out you've just lost half your foveal field of vision. I don't think that human vision will be able to fully filter it out all the time. The only way to do that is pretty crazy, requires perfect striping and would need the eyes to be slightly out of vertical alignment. It's just silly. Even at a glance without comments in the way there's a benefit to seeing the structure of code uninterrupted.
The point is it's just YAGNI or bloat and if you find yourself having to write rosetta code then that might raise a few questions. Perhaps your standards for your target audience are too low for example. I often deal with a lot of thick sophisticated code even after a heavy dose of DRY and if I also had to maintain a swamp of comments as well as good code it would ruin my life. As with most things, code, comments, etc usually too little is better than too much. If you do too much it will almost never show directly. If you do too little, it will eventually announce itself. This is just a fundemental rule. For comments your minimum standard tends to be doc comments although if your codebase is not well designed and subject to a lot of alteration this can be a problem as it will introduce massive drag. To be honest, a huge number of codebases do not even bother with doc comments which can be a bit of a shame.
The number one rule is don't do something unless it is needed or really adds value. The shame of it is people tend to interpret this as not having to bother to name variables properly, indent properly, escape properly, handle errors properly, handle unexpected cases properly, etc. There is another golden rule that becomes apparent and it is a bit of an unfortunate one. In terms of maintainability, time spent on code tends to be far more valuable than comments. It's only occasionally that comments are valuable enough to put in. So unless you have lots and lots of resources to dedicate on a codebase to get every aspect perfect and close to correct the first time then you're not going to want to indulge too heavily on comments.
I'm not against comments but I am against comments for the sake of comments and every detail matters. You can't say it doesn't matter because it's a bit less obvious, because it is shaded out. It's still there, it still has an impact. I do have it a bit easy because I've worked on a lot of other codebases, opensource, inherited, my own after years and so on so I am fairly confident about exactly how far I need to go with comments to uphold a good level of maintainability. It's quite often when working on my own codebases that when I find a bug and finally trace it to the line there will be a comment there giving warning about an uncertainty or an unhandled case. There are cases where you have to work out intention but that becomes easy after a while especially after failing all else you can establish your own intentions which are usually about as good or lead you down the right path.
You haven't unmade my point but rather you've raised a few points about yourself. Sure, assists are helpful sometimes and relevant to this discussion. What isn't is your attempt to push comments as a zero cost artifact and your over confidence. You seem to be pushing for comments for the sake of comments if your trying to push a zero cost agenda and that simply isn't viable. It's an extreme position to take. I don't know if you're trolling or what because on the face of it it's just silly pseudo expert stuff. It's almost comedic. Are you being sarcastic and trying to immitate a type of person with mockery? Because if you're just going to have your IDE dull them like that so you can filter them out so you can ignore them you might as well then delete them because it seems they must be pretty useless if you don't need to see them. In fact the example I gave specifically was that they were useless so you're saying it's fine to have useless stuff because you can lowdark it.
The thing is though, I would like something like effectively zero cost comments at least from my perspective and in relation to my coding styles. For me the best thing in that vain is external documentation but the problem is with that is that it drifts just as the rails guy alludes to in a way. Commits are a good start, the only thing is that it's just a single string and you would have to manually point out lines in code, files, etc. I use something for code review that allows comments per line and so on. It might be nice to see something like that integrated into a VCS per commit (and to have a commit that purely adds comments like this). This can also drift over time but as the rails guy points out, initially it maps to a point in time so you can trace its ancestry basically in the same way you might do blame, etc. I say zero cost but nothing is literally zero cost. It would still allow me and others to be far more gratuitous with comments though with less of a concern about cluttering code and without such an obligation to maintain comments added to the same degree.
If shading them gets them out of the way for you in your circumstances then that is absolutely fine. That doesn't entitle you to dismiss the notion that other people might want superfluous comments completely out of the way of their code.
Admin
I forgot to add a bit. If you reach a point where you struggle with the German, 99% of the case that's a matter of RTFM. Your German sucks and the solution to that is to not embedded the English-German dictionary throughout the document but to brush up on your German. If it's the 1% case then perhaps add a comment, it may be needed in that case. For a fluent developer things are switches, 99% is a case that needs a comment, 1% is a case that language comprehension fails. However, such developers often only have a problem understanding the code once per thousand or more lines of it unless someone has written code in a way that is somehow obfuscated like using only expletives for variable names.
Admin
Comments: Brief, entertaining, useful If its not 2 of those 3 then don't bother
Admin
Not necessarily. I like to keep my tickets in the repository so that I don't lose track of them, so the ID (the only useful bit) remains useful. Yes, a blame log might help, but it doesn't really help very much when you're dealing with code that's a few decades old; some things live for a long time, in some cases out-surviving their original authors entirely.
Admin
Do you have the reference to that? That's a great "Thought of the day" for our board.
Addendum 2016-08-25 10:05:
Admin
I'm on the fence when it comes to this. It does explain the "why" the code is like this (look in the bug ticket, minimal typing by the developer: all the information is in the bug-tracking system). When I think a bit of code needs the extra clarification, I do often add the ticket number and try and add a short comment so that at least I can show more reasons behind this strange logic methods.
But there is always the risk of losing that information when moving between bug-tracking systems. Even on our project we've changed JIRA prefixes four times in three years. You know the age of the bug fix/feature request by the prefix left in the code. Luckily though that searching for the old prefix automatically redirects to the current ticket.
I even came across some code today that was marked with an ancient ZenDesk ticket number (in use before JIRA) which shed some light on WTF this thing is. The git commit message was basically the svn revision number with the message something like "Thursday" along with 200 other unrelated files in the one commit (svn history was imported into git).
Admin
The comment should be:
THIS comment makes sense with reference to logged bugs. It is of no use to know the bug number within the code if I have to look it up. We don't need to read the entire bug report to know what the fix was for. It is also helpful to see this in the actual code where the fix occurs:
And here, it is obvious the code was changed so instead of a hard-coded list this information is gathered from the numbers on the actual product records from inventory so that the possible box quantities are displayed in real time. It is not necessary to comment every line in the code ("create a new integer for use as a counter in the array", "cycle through the array", "return the value of the array index", "add one to i"). There isn't reason to put other comments in there unless you have a need to accommodate special cases or if the code may be seen as WTFery because it's not so obvious how the code does its job. Maybe there's 24 in a box but this particular item is sold in 12-box pallets, so the actual quantity is 288? Maybe you need to do voodoo or majick to get the database to spit up information because of the way the data is arranged? I dunno... just making that part up. And, absolutely under no circumstances is there any reason to comment out the old code that was changed so it's still visible. I have seen code where small revisions over the years have resulted in 10 lines of the same variable assigned different values, with 9 of them commented out AND each containing a comment as to the reason for the change (and change back when that didn't work).
Yep, tags might be a problem if you change systems and/or prefixes. Makes no sense to import and renumber all your bugs and refactor all your code to contain the new numbers on the new system, and it may or may not be possible to save all the information from the old system for a variety of reasons. But if you have short meaningful comments like this in the code along with full descriptions in bug reports and a happy medium in the commit log you will make a lot of people happy when they need to review your code.
Admin
"highlighting, code folding, extra provide an assist but that's all they do. They do not eliminate the problem entirely." Making a problem disappear isn't the only way to deal with a problem. Making it very easy to deal with to the point it becomes trivial is most of the time the most cost-effective solution. Following your reasoning you shouldn't have a car because you still have to walk a little after you get out of it, thus "they do not eliminate the problem entirely".
I "push for comments for comments' sake" just as much as you push for a "absolutely no comments allowed" stance, i.e. I don't. You really streched my comment wide with a lot of suppositions and guesswork. Next you might say I think like that due to a rough childhood or an abusive teacher or some other BS. You seem to be under the impression that I love littering my code with "//adds 1 to i" for every i++ I write. That's an erroneous assumption and it's entirely on you. I like having a small comment above a line that is more complex than the average. At this point I usually have two choices, either a slightly above average complexity single line which I clarify with a one-line comment that will later confirm what I suspect that code does or I can unroll that code line unto a 20 lines block of code to do the same thing with lesser complexity, thus not needing any comments. Per your previous post you appear to like the codeblock approach more (as it is self-commenting). But then wouldn't that block require more of the screen estate? Wouldn't your eyes need to move more? (By the way, your argument could easily be used to defend a removal of blank lines. I don't think you really agree with that)
"Because if you're just going to have your IDE dull them like that so you can filter them out so you can ignore them you might as well then delete them because it seems they must be pretty useless if you don't need to see them. In fact the example I gave specifically was that they were useless so you're saying it's fine to have useless stuff because you can lowdark it." Most of the time my brain is in high gear and I don't need that one-line comment to immediately get what the line it references does. But I'm human (maybe you're not?) thus sometimes my brain is in a slow gear or in need for a coffe and that comment line helps me get what the code is supposed to do. And when I'm on a high gear it will still be alright that it's there because I'll just tune it out.
Once again, let me remind you: I'm not advocating being swamped in comments. That would drown the code in noise, as you said. But if you have let's say 6 comment lines spread over a screen displaying 40 lines of code I find that extremely easy to deal with.
As in all things in life, there's a call for moderation. Too much of a thing is bad, too little is bad, I defended having a bit more than you think is adequate and you responded as if I was advocating for a sea of comments in which a solitary line of code floats.
Admin
I would have to agree with you. Having "a bit more" is better than having too few or none.
Admin
You're shifting the goal posts here. I'm specifically not in favour of knuths approach, at least not universally. I occasionally do the same myself but it's as needed. Knuth talks about writing it all out in natural English first and then interspersing the code into that. Some of us write code natively and fluently so that's really excessive a lot of the time and makes for rosetta code which most of the time is bad. As I have pointed out there are places where comments are appropriate and rules for that. Beyond doc comments, programmatic annotation and justified rosetta code according to the laid out premises where it is justified there's really little reason for many comments at all. If you find yourself having to comment many lines of code a lot, you might have too little faith in your own memory or ability to read code at a high level where you can deduce intention. I haven't actually said that you should have no comments at all but that you basically only add them according to the need and justification. The example I gave was also of interleaved comments. I haven't listed all the rules though or in detail. One rule is for example is that you're likely to want to comment assembly with a very high ratio of comments to lines.
This isn't actually about you if you go back to the original thread. It's about the time Knuth lived in, the time now and that the rails developer might have actually been onto something. You directly replied to by first, I simply replied to the thread on the reputability of rails developers with their designer satchels and groupies adding my own take on the comments situation as it has evolved. You've somehow lost sync.
There's another darker side of this as well though with me. My codebase is my codebase and yours is yours so really what you want to do with yours doesn't concern me. However when it comes to the subject of comments there is a a philosophical side to it. Many people feel compelled to put in comments to help their fellow man and to not be selfish. It's one motivator for comments for the sake of comments.
You reach a point though where you must ask, how much should I really invest in other people's literacy? I invest a lot in mentoring people but there is only so far I will go in poluting the codebase. When I hire people, I hire qualified people that are up to the task or respond appropriately to training. It's just one of those things. You expect people to be able to read and write when hiring them for a normal job and for programming you expect the same but you expect them to be able to read and right code. If I have to pepper a lot of innane superfluous comments around for someone else's benefit while actually impeding my own productivity as well as that of others they aren't quite up to spec and that's something you deal with more directly. For me that's a lot of training, pair programming, code review and so on. It can be hard given the demand to get good people so this is a normal part of the process. I spend almost as much time tutoring as I do programming. The code that is actually done and is worked on however is not a toy purely for learning. When it comes to that they need to pull their weight and rise to the challenge of stepping up their game when it comes to code comprehension. They are the ones being paid and they are usually supposed to already know the language well so that's the harsh reality of it. It's not a playground or a sandpit but serious business, real world work, not something in a class room or that you do at home in your bedroom. That said there is a balance and I do sprinkle comments around where appropriate. This is something I am sensitive about. I spend an ordinate amount of time dealing with other people's junk. I don't get that much time to do my own things and I'm often held back from doing the pretty awesome things that I want to and can do. I am a passionate programmer. Time and time again however I have had to inherit from people that basically made the wrong career choice. They don't have the DNA, they don't have the potential, they will never be good enough. When you're not actually that smart but you constantly find yourself having to fix code from people who have been programming for twenty years yet are not even close to your level when you were a kid after a few years programming as a hobby this is something that you really get a chip on your shoulder about. It's not from elitism and I've never really considered myself amazing. It's from the the sheer amount of incompetence often coupled with vulgar attitudes that consumes my efforts when I just want to make great things with great people. You can see a bit of that in my comments on your code might be unmaintainable. Put it this way, the god awful code I've had to tackle time and time again, a lack of comments is the absolute least of my concerns. No amount of comments could compensate for the kind of things that have ended up in my hands (usually because no one else could fix the mess). To be fair a few extra comments doesn't bother me either really. I usually just delete them without looking to get the distractions out of the way. In the worst case they're still their in the VCS.
If you're still learning at an earlier level that is fine and nothing to be ashamed of but you really should be aspiring to work towards this level where you can work with pure code up front. It can take time to get fluent and good with doing things the harder way but you wont regret it because being able to read code fluently, quickly and efficiently is an empowering skill that you can take far beyond anything comments can. The code at the end of the day is what runs and what is actually relevant. Nothing else.
Your complicated line argument seems to be a bit of a reach at gaining an equaliser. I've barely seen a line of code that on its own it too complicated except a few I've done on purpose for a laugh and it's never been that a comment has been a better option for expressing something differently which would pretty much result in the same net size. It's an outlier, I don't think it applies. If there is such a case it will because I don't know what a library function does so I will need to check the manual and then learn it. That's no big deal, that's what you are meant to do. You go to the manual, it is unreasonable for the manual to come to you. There is one ironic exception to that because it's IDEs which can integrate a manual, let you look up a definition and so on although personally I'm happy with a powerful text editor given the number of languages I often have to work with in and given day. Where things are spread out more the eye track guide can outweigh the benefit of a tiny slight increase in movement of the eye. Comments don't correlate with that. I find it more the case that I can be more expressive with a blank line than a line with a comment in it. I don't think what you said is entirely valid but ultimately it's something on the fringe that is silly and not really favourable towards comments when it might happen. You're comparing a 1/999 thing to my 50/50 example. Basically, whether you add comments or not it really should have very very little impact on the width, height or density of your actual code either way.
I do have a horrible confession to make however. When I started coding I wrote well organised but almost entirely minified code. Since then I have slowly added bits as they have served a purpose. I have a highly readable style now because over the years there has been nothing I've added that hasn't had some value starting from nothing. Beyond doc comments, external documentation and special cases, comments really have never added much value. There has nearly always been something better. I am fairly accurate with this and that is actually useful to other developers. I don't waste comments so if someone else takes a look at my code and sees that they also know it's something they probably ought to double check. More often than not when fixing something it tells them immediately where to look first.
6/40 isn't too bad. It's a good way off from rosetta code. I'd still say it seems a little high as I do about 1/500 or so for comments within functions overall. One the other hand it's hard to judge without any idea what your language or algorithm is. I've got one piece of crucial business logic that comes close to being rosetta commented. Never had any major problem revisiting a piece of code I wrote and completely forgot about years later so I'm not really too worried.
This is the Knuth method:
https://en.wikipedia.org/wiki/Literate_programming
This is fun but not what I mean by rosetta comments:
https://www.rosettacode.org/wiki/Comments
I've had a nice idea which would be to modify pre commit hook to filter out specially annotated comments such as:
It would be very easy to have the VCS relocate these in the commit message including the line number keeping in mind other strips. I could then alter the VCS view to interpret these commits, perhaps database the comments to have an index against the file and to then be able to show them when viewing the code in the VCS. The problem is with the VCS I currently use commit works in one direction so it would be a horrible hack to get it to work bidirectionally and would also introduct possible unexpected behaviour that would constitute a bit of a WTF. A simple command line tool could be another option.
Admin
Những người bán nhân sâm Hàn Quốc cho biết, nhân sâm được trồng và nhân giống tại nhiều nơi. Tùy vào đặc điểm nguồn nước, thổ nhưỡng và khí hậu mà hoạt tính cũng như giá trị nhân sâm khác nhau. Do chỉ bảo quản tối đa được trong vòng 7 ngày nên nhân sâm tươi Hàn Quốc đưa về Việt Nam phải được bảo quản ở nhiệt độ thấp. Khách hàng có nhu cầu mua nhân sâm Hàn Quốc ở đâu tại Việt Nam cũng phải đặt hàng trước khoảng 2-3 ngày, đặc biệt là khi mua loại nhân sâm Hàn Quốc 6 năm tuổi.
Nhân sâm là sản phẩm chăm sóc sức khỏe cao cấp của Hàn Quốc. Nhân sâm Hàn Quốc được đánh giá là một trong những sản phẩm ưu việt qua quá trình chế biến thì hàm lượng ginsenosides được tăng lên rất nhiều, nhân sâm lại mang tính ôn nên phù hợp với nhiều đối tượng và đặc biệt là rất tiện dụng cho cuộc sống hiện đại.