Skip to content

Mirror of 376#15

Open
illicitonion wants to merge 1 commit into
CodeYourFuture:mainfrom
illicitonion:implement-shell
Open

Mirror of 376#15
illicitonion wants to merge 1 commit into
CodeYourFuture:mainfrom
illicitonion:implement-shell

Conversation

@illicitonion

Copy link
Copy Markdown
Member

No description provided.

@illicitonion illicitonion added Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. NotCoursework labels Jul 6, 2026
@cyf-ai-code-reviewer

Copy link
Copy Markdown

Thanks for opening a new PR! AI started to review it. Please notice that AI will review this PR only once

@cyf-ai-code-reviewer cyf-ai-code-reviewer Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are many code comment that doesn't provide much value. Could you please check if some comments can be removed, for example comments that just repeat what code does?

Comment on lines +14 to +21
if(options.numberNonEmpty) {
//-b option: number non-empty lines
if(line.trim()) {
process.stdout.write(
`${String(globalLineCounter).padStart(6)}\t${line}\n`
);
globalLineCounter++;
} else {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the printFile function, the logic that formats and prints numbered lines is repeated for both the -b (number non-empty) and -n (number all) options. In both branches you:

  • Convert globalLineCounter to a string
  • Pad it to width 6
  • Add a tab
  • Append the line content
  • Then increment globalLineCounter.

The only real difference between the two branches is when numbering is applied (all lines vs non-empty). When similar formatting logic appears in multiple branches like this, it can make later changes a bit harder: if you decide to adjust the formatting (for example, change the padding or separator), you’d need to remember to update it in every place. How might you extract the shared “print numbered line and increment the counter” behavior into a single helper, and then call it from both the -b and -n paths so that the format is defined in just one place?

To "like" or "dislike" this comment, please follow this link

Comment on lines +12 to +21
function printCounts(filePath, counts, options) {
const parts = [];
if(options.line) parts.push(counts.lines);
if(options.word) parts.push(counts.words);
if(options.byte) parts.push(counts.bytes);
//if no specific count options are provided, print all counts
if(!options.line && !options.word && !options.byte) {
//default is to print all counts
parts.push(counts.lines, counts.words, counts.bytes);
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In printCounts, you’re building up the parts array in two ways: first by checking each option individually (-l, -w, -c), and then again pushing all three counts when no options are provided. This leads to repeating access to counts.lines, counts.words, and counts.bytes in two separate blocks. While this works correctly, it does mean that if you ever wanted to change the order or add another dimension, you’d have to keep both sections in sync. Could you think of a way to describe the available counters and their corresponding options once (for example in a small structure or loop), and then derive both the “only selected fields” and “all fields when none selected” behaviors from that single description?

To "like" or "dislike" this comment, please follow this link

Comment on lines +47 to +48
const filePatterns = [];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filePatterns is later used directly as the list of files to read, without any pattern/glob expansion. For a reader, the name filePatterns usually implies something like wildcard patterns (*.txt) that will be expanded or matched, not plain file paths that are used as-is. If someone later tries to add real pattern support, or just reads the code quickly, this name could make them overestimate what this array contains. How might you rename this so that it more clearly communicates that these are the raw file arguments/paths you’re going to open?

To "like" or "dislike" this comment, please follow this link

Comment on lines +26 to +27
const directories = args.filter(arg => arg !== '-a' && arg !== '-1');

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The directories array actually holds all non-option arguments, and you then treat each element as either a directory or a file (you call fs.statSync(arg) and may print the name directly if it’s a file). Naming this array directories suggests it only contains directories, which can mislead a reader into thinking there are no files in that list. That can make the later stats.isDirectory() branch a bit surprising to follow. Could a more neutral name that reflects "paths" or "args" make the intent clearer and reduce that confusion?

To "like" or "dislike" this comment, please follow this link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. NotCoursework

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants