Skip to content

Mirror of 390#7

Open
Droid-An wants to merge 5 commits intoCodeYourFuture:mainfrom
Droid-An:mirror-of-390
Open

Mirror of 390#7
Droid-An wants to merge 5 commits intoCodeYourFuture:mainfrom
Droid-An:mirror-of-390

Conversation

@Droid-An
Copy link
Copy Markdown
Collaborator

No description provided.

@Droid-An Droid-An added the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Mar 29, 2026
@cyf-ai-code-reviewer
Copy link
Copy Markdown

Thanks for opening a new PR! AI started to review it

@github-actions

This comment has been minimized.

@github-actions github-actions bot removed the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Mar 29, 2026
Comment on lines +31 to +42
def filter_hidden(files: list[str]) -> list[str]:
return [name for name in files if not name.startswith(".")]


def get_visible_entries(files: list[str], include_hidden: bool):
return files if include_hidden else filter_hidden(files)


def format_entries(files: list[str], one_per_line: bool):
if len(files) == 0:
return
print(("\n" if one_per_line else "\t").join(files))
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 parameter 'files' in 'format_entries', 'filter_hidden', and 'get_visible_entries' is used for both files and directory entries, which could be files or directories. Do you think a more general name like 'entries' would make it clearer that these lists can contain both files and directories?

Comment on lines +76 to +79
for directory, contents in result_dirs.items():
print("\n" + directory + ":")
filtered = get_visible_entries(contents, include_hidden)
format_entries(filtered, one_per_line)
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 section where you print directory contents for multiple directories, the logic for filtering and formatting entries is repeated. If you needed to change how entries are displayed, you'd have to update it in more than one place. How could you refactor this to avoid repeating yourself?

@github-actions

This comment has been minimized.

@Droid-An Droid-An added Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. NotCoursework labels Mar 29, 2026
@cyf-ai-code-reviewer
Copy link
Copy Markdown

Thanks for opening a new PR! AI started to review it

Comment on lines +35 to +36
def get_visible_entries(files: list[str], include_hidden: bool):
return files if include_hidden else filter_hidden(files)
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 function 'get_visible_entries' returns either all files or only non-hidden files, depending on the 'include_hidden' flag. The name 'get_visible_entries' might suggest it always returns only visible (non-hidden) entries, but it can also return hidden ones. Could you think of a name that more clearly describes what this function does based on its parameters?

@Droid-An Droid-An added Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. and removed Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. labels Mar 29, 2026
@cyf-ai-code-reviewer
Copy link
Copy Markdown

Thanks for opening a new PR! AI started to review it

Comment on lines +58 to +62
# Is a file?
if stat.S_ISREG(st.st_mode):
result_files.append(file_path)
# Is a directory?
if stat.S_ISDIR(st.st_mode):
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I've noticed that you have comments like '# Is a file?' and '# Is a directory?' right above the code that checks if a path is a file or directory. Since the code itself (using stat.S_ISREG and stat.S_ISDIR) is already quite clear about what it's doing, these comments don't add much value. When code is self-explanatory, extra comments can sometimes make the code harder to read by adding clutter. How might you decide when a comment is truly helpful versus when the code speaks for itself?

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