Merge pull request #15 from Gitanuj993/main

[Gitanuj993]

Merge pull request #14 from Gitanuj993/fix

[github-actions]

🤖 AI Code Review

As an expert software engineer, I've reviewed your codebase. Here's a breakdown of my findings:

Bugs

1. Future "Last Updated" Date (./public/index.html):
   • The date "Last Updated: 3rd July 2026" is hardcoded in the future. This is misleading to visitors. It should be updated to the actual last modification date or removed if not dynamically maintained.
2. Vague Percentages in "Libraries & Modules" (./public/index.html):
   • Entries like "STL (C++) – Data structures & algorithm optimization , 3%" include a percentage (e.g., "3%", "1%") that is not explained. This information is unclear and could be confusing or misleading for a viewer.
3. Empty Project Sections (./public/index.html):
   • The <ul> tags under "C++ Projects" and "Python Projects" are empty. This makes these sections appear incomplete or unfinished to visitors.
4. Missing Footer Script on projects.html (./public/projects.html):
   • The projects.html file includes <header id="navbar"></header> and a corresponding navbar.js script, but it has <footer id="footer"></footer> without including assets/js/footer.js. As a result, the footer component will not be dynamically loaded and rendered on the Projects page.
5. Misnamed and Redundant JavaScript Functions (./public/assets/js/*.js):
   • editorial.js, contact.js, blogs.js, and projects.js all contain the identical, empty function initializeAboutPage(). This is a clear copy-paste error. The function name is incorrect for the respective pages, and the function itself serves no purpose.

Security Issues

1. Exposed Web3Forms access_key (./public/index.html):
   • Your Web3Forms access_key is directly embedded in index.html. This key is publicly accessible in the client-side code. While Web3Forms may tolerate this for free/low-volume usage, it's a security risk. Anyone can inspect your page, extract this key, and use it to submit spam to your form endpoint, potentially depleting your submission quota or even getting your key rate-limited/blocked. For better security, such keys should ideally be proxied through a server-side (or serverless function) endpoint, keeping them out of client-side code.

Performance Improvements

1. Image Optimization:
   • Ensure that the preview.jpg and favicon.png (referenced in index.html) are optimized for web delivery. This includes proper compression, appropriate sizing for their display context, and potentially using modern image formats (like WebP) where supported. No image files were provided in the review, so this is a general best practice.
2. Consolidate Small/Empty JavaScript Files:
   • The page-specific JS files (about.js, editorial.js, blogs.js, contact.js, projects.js) are currently empty or contain only a placeholder function. If these files don't implement any unique functionality, consider removing them or consolidating common initialization logic into a single, shared utility script. This would reduce the number of HTTP requests and file size.
3. Use defer for JavaScript Loading:
   • For scripts that don't need to block initial page rendering (like index.js and other page-specific scripts), adding the defer attribute to their <script> tags (<script src="..." defer></script>) is good practice. This allows HTML parsing to continue unimpeded, potentially improving perceived page load times.
4. Dynamic Component Loading (Minor):
   • Loading the navbar.html and footer.html dynamically via JavaScript fetch introduces additional network requests and a slight delay in rendering these components. For static content like a portfolio, including these components directly in the HTML (or using a static site generator/build process to inject them) can be slightly more performant and simpler. This is a minor point for a small site, but worth noting for larger applications.

Code Quality Suggestions

1. README Completeness (./README.md):
   • Fill in all sections currently marked with ? (Badges & info, Tech Stack Used, Project Structure). A comprehensive README is crucial for collaborators and anyone trying to understand your project.
2. CSS Variable Consistency (./public/assets/css/index.css, ./public/assets/css/about.css):
   • Inconsistent Usage: index.css uses hardcoded color values (e.g., #0d1117, #e6edf3, #58a6ff) instead of leveraging the CSS variables (e.g., var(--bg-color), var(--text-color), var(--accent-color)) defined in global.css.
   • Redundant Declaration: about.css redundantly declares its own :root variables. Critically, some of these (e.g., --surface-color:lightgray; --border-color:red;) are inconsistent with the global theme variables. The global variables defined in global.css should be the single source of truth and used consistently across all stylesheets without re-declaration.
3. Remove Commented-Out Code (./public/assets/css/global.css, ./public/assets/js/index.js, etc.):
   • Remove large blocks of commented-out code (e.g., the extensive main, nav styles in global.css, the old form submission logic in index.js, commented resume link in index.html, commented links in navbar.html). Clean code should only contain active code.
4. Improve index.html Keywords (./public/index.html):
   • The meta name="keywords" content is a bit verbose and conversational. Keywords should be concise, comma-separated terms or short phrases that are highly relevant to search engines (e.g., "Anuj Tanwar, portfolio, software engineer, backend development, DSA, scalable software").
5. Remove Redundant Web3Forms Field (./public/index.html):
   • The _next field in the Web3Forms form is deprecated; the redirect field serves the same purpose. Remove _next for cleaner form configuration.
6. HTML ID Naming Convention (./public/index.html):
   • The div with id = "Resume" has an extra space (id = "Resume"). While browsers are forgiving, it should adhere to standard attribute syntax id="Resume".
7. vercel.json deploymentEnabled:
   • git.deploymentEnabled: false means Vercel won't automatically deploy on Git pushes. If automatic deployments are desired, this should be set to true. If false is intentional (e.g., manual deploys, or using a separate CI/CD), adding a comment explaining the decision would improve clarity.
8. Empty Placeholder Files (./public/logo/Images.md, ./public/assets/data/*.json):
   • The Images.md and all .json files in public/assets/data/ are empty. If these files are not intended to be used or populated, they should be removed to keep the repository clean.
9. Navigation Consistency (./public/components/navbar.html vs. ./public/index.html):
   • The navbar.html has "Projects" and "Contact" links commented out, but index.html clearly features sections for "Projects" and "Connect" (which implies contact). This creates a disconnect. Either enable the navigation links or remove the corresponding sections from index.html if they are not meant to be full pages.

Final Score (/10)

Score: 5/10

Reasoning:

The codebase establishes a basic, functional portfolio website with a clear intention for structure and content. It utilizes fundamental web technologies (HTML, CSS, JavaScript) effectively for static content and includes dynamic component loading and a contact form. The use of CSS variables in global.css and good SEO meta tags are positive aspects.

However, the score is significantly impacted by:

• A critical security vulnerability: Exposing the Web3Forms API key directly client-side is a major concern.
• Multiple functional bugs: The future-dated content, vague data, empty sections, and broken footer on one page directly detract from the user experience and site's credibility.
• Numerous code quality issues: Inconsistent CSS variable usage, redundant/misnamed JavaScript, significant amounts of commented-out code, and empty placeholder files suggest a lack of polish and attention to detail. These issues make the codebase harder to maintain, understand, and scale.
• Incompleteness: Many sections and pages are essentially placeholders, indicating the project is either very early in development or not actively maintained.

While the foundation is present, the presence of security issues, functional bugs, and considerable technical debt in code quality prevents a higher score. Addressing these points would significantly improve the project's reliability, maintainability, and security posture.