문제 솔루션 모음집

여러 온라인 저지의 문제 풀이를 한곳에 모아 GitHub Pages로 제공하는 저장소입니다.

집단 지성 프로젝트를 백준 문제집에서 진행하였지만 확장을 위해 솔루션만 따로 빼서 새로운 레포지토리로 이전을 하였습니다.

🌐 솔루션 사이트

main 브랜치의 솔루션은 정적 사이트로 생성되어 GitHub Pages에 자동 배포됩니다.

• 사이트: Algorithm Solutions
• 문제 번호와 제목을 검색하고 플랫폼·언어로 필터링할 수 있으며, 결과는 30개씩 표시됩니다.
• 작성자·공동 작성자·제출 링크와 풀이 설명은 코드에서 분리해서 보여줍니다.
• 저장소의 announcements/*.md에 올린 공지는 사이트의 공지사항 탭에서 모아볼 수 있습니다.

📕 문제 풀이 컨트리뷰트 가이드라인

이미 푼 문제가 많지만 옛날에 푼 많지만 코드가 깔끔하지 않아 다시 새로 풀려고 합니다. 하지만 저 혼자 하기에는 너무 많은 시간이 필요하고 다른 일도 하는게 있어서 BaaaaaaaarkingDog님이 하신거와 같이 집단 지성 프로젝트로 만들어보려 합니다.

아래 있는 규칙은 BaaaaaaaaaaarkingDog님이 작성하신걸 참고하여 적었습니다.

📁 Repo 폴더 구조

백준 문제집 레포에서 올리던 방식과 다릅니다.

기본적으로 아래경로처럼 구성되어 있습니다.
solutions/{온라인 저지 플랫폼}/{문제 번호}/{파일 이름}

백준

백준 문제 솔루션인 경우, 백준 A+B 인 경우 solutions/baekjoon/1000/main.cpp처럼 구성되어 있습니다.

릿코드

릿코드 같은 경우는 문제 제목 옆에 문제 번호가 있습니다. 따라서, 해당 문제의 솔루션인 경우 아래 경로처럼 위치해야합니다.

solutions/leetcode/1074/main.cpp

프리미엄 문제를 제외한 모든 LeetCode 문제의 제목과 원문 URL을 pages/config.yaml에 갱신하려면 저장소 루트에서 다음 명령을 실행합니다.

make update-leetcode

프로그래머스

프로그래머스는 문제를 들어가보면 주소창에 문제 번호가 있습니다. 예를 들어, https://school.programmers.co.kr/learn/courses/30/lessons/151138에서 151138이 알고리즘 번호로 생각하시면 됩니다. 따라서, 해당 경로는 아래처럼 위치하면 됩니다.

solutions/programmers/151138/main.py solutions/programmers/151138/main.sql

해커랭크

HackerRank는 문제 URL만으로 숫자 식별자를 얻을 수 없으므로 maintainer가 배정한 양의 정수 식별자를 사용합니다. 새 문제를 추가할 때는 pages/config.yaml에도 문제 제목과 원문 URL을 함께 등록해야 합니다. 예를 들어 Select All 문제의 식별자가 8137이면 다음 경로를 사용합니다.

solutions/hackerrank/8137/main.sql

💻 Contribute 에 대한 설명

이미 존재하는 풀이가 있을 경우 Merge가 안될 수 있습니다. 이미 존재하는 솔루션과 다른 풀이인 경우 파일명을 Maintainer가 직접 바꾼후 Merge합니다.

아래 기준을 맞추어 여러분들의 Solution Code를 main branch로 Pull Request (PR) 해주시면 됩니다 !
Pull Request에 대한 설명은 여기에서 보시면 됩니다.

현재 이 Repo는 코딩테스트를 준비하시는 분들을 위해 만든거라 언어는 C, C++, Java, Python 3, Javascript(Node.js), Kotlin, Rust, Swift, Go 총 9가지 언어만 허용합니다. 각 언어에 대한 솔루션 파일명과 제출 언어(ex. C++17)는 아래만 허용합니다.

Language	파일명 및 확장자	백준 제출 언어
C	main.c	C2x, C11
C++	main.cpp	C++14, C++17, C++20
Python 3	main.py	Python 3, PyPy3
Java	Main.java	Java 8, Java 11, Java 15
Kotlin	main.kt	Kotlin (JVM)
Node.js	main.js	node.js
Rust	main.rs	Rust 2015, Rust 2018, Rust 2021
Swift	main.swift	Swift
Go	main.go	Go
데이터베이스	main.sql

Rule

필수 - 반드시 아래 규칙들을 지켜주세요. 위배되는 솔루션 코드가 있으시 Reject 됩니다.

해당 규칙은 추가, 수정, 삭제가 될 수 있습니다.

• Rule 0 : (백준 문제 한정) (모든 언어 공통)표준입출력으로 풀어야 합니다.
• Rule 1 : 다른 사람의 솔루션을 자신이 푼 것처럼 Pull Request (PR) 하시면 절대❗️ 안됩니다.
• Rule 2 : 아래 형식으로 솔루션 맨 위에 정보를 넣어주세요. Authored by는 필수이며 각 플랫폼 닉네임을 사용해야 합니다. Co-authored by와 제출 결과 Link는 없으면 줄 자체를 생략할 수 있습니다. 값을 적을 때는 주석, 키, 콜론의 공백을 예시와 동일하게 작성해주세요.

백준

해당 PR을 확인해주세요.

// Authored by : tony9402
// Co-authored by : -
// Link : http://boj.kr/3ee3d9284f2e4fd7b92b2a22e17d02d6

릿코드

해당 PR을 확인해주세요.

// Authored by : tony9402
// Co-authored by : -
// Link : https://leetcode.com/problems/palindrome-number/submissions/1163121115

프로그래머스

제출 링크가 없으면 Link 줄을 생략할 수 있습니다. 해당 PR을 확인해주세요.

// Authored by : tony9402
// Co-authored by : -
// Link : 

해커랭크

제출 링크가 없으면 Link 줄을 생략할 수 있습니다. 해당 PR을 확인해주세요.

// Authored by : tony9402
// Co-authored by : -
// Link : 

• Rule 3 : Pull Request (PR) 하나 당 솔루션 하나만 있어야 합니다. 같은 문제여도 언어마다 다르게 PR을 보내야 합니다. 이는 관리의 편의성을 위해 적용합니다.
• Rule 4 : Allow edits by maintainers 옵션을 허용으로 둬야합니다.
• Rule 5 : 분류에 맞는 솔루션을 올려야 합니다.
• Rule 5 : 맨 아래에 Solution Description 블록을 추가해주세요. 풀이 설명은 작성할 내용이 있을 때 블록 안에 적고, 없으면 블록을 비워둘 수 있습니다.

C, C++, Java인 경우 
/* Solution Description
*/

Python인 경우
""" Solution Description
"""

각 언어의 주석에 맞게 변경해주시면 됩니다.

Pull Request 자동 형식 검사

솔루션 PR은 solution-format 검사에서 다음 항목을 자동으로 확인합니다.

• PR에서 추가하거나 수정한 솔루션 파일이 1개인지 확인합니다. 해당 문제의 pages/config.yaml, 테스트, 문서 변경은 함께 올릴 수 있습니다.
• solutions/{플랫폼}/{문제 번호}/{파일명} 경로와 허용 언어/파일명을 검사합니다.
• Authored by가 파일 첫 줄부터 표준 주석 형식으로 작성되었는지 검사합니다.
• 선택적인 공동 작성자와 제출 링크가 올바른 형식인지 검사합니다.
• 신규·수정 솔루션에는 정상적으로 닫힌 Solution Description 블록이 있어야 하며, 내용은 비어 있어도 됩니다.
• 메타데이터와 설명을 제외한 실제 코드가 있어야 합니다.
• LeetCode/HackerRank처럼 문제 번호만으로 URL을 만들 수 없으면 pages/config.yaml에 문제 링크를 등록해야 합니다.

검사가 끝나면 성공·실패와 관계없이 파일, 문제, 오류·경고 상세 결과를 PR 댓글로 남깁니다. PR에 새 커밋을 push하면 검사를 다시 수행하고 기존 봇 댓글 하나를 최신 결과로 갱신합니다. 오류가 있으면 Actions 화면과 PR check에도 파일명, 줄 번호, 오류 코드가 표시되며 병합할 수 없습니다.

로컬 PR 사전 점검

PR을 올리기 전에 전체 솔루션 형식만 빠르게 확인하려면 저장소 루트에서 다음 명령을 실행합니다. 별도의 pre-commit 도구를 설치하거나 먼저 git add할 필요는 없습니다.

make precheck

전체 테스트와 GitHub Pages 임시 빌드까지 모두 확인하려면 다음 명령을 실행합니다.

make checkall

precheck는 기존 솔루션 전체를 호환 모드로 확인하고, 기준 브랜치와 비교해 변경된 솔루션은 strict 형식과 문제 링크까지 각각 검사합니다. 여러 솔루션을 로컬에서 한꺼번에 준비해도 모두 검사할 수 있지만, 실제 솔루션 PR은 기존 규칙대로 하나의 파일만 포함해야 합니다.

두 명령 모두 origin/main과 현재 브랜치의 공통 조상을 기준으로 커밋된 변경뿐 아니라 staged, unstaged, untracked 파일도 함께 확인합니다. 대상 브랜치가 다르면 make precheck BASE_REF=브랜치명 또는 make checkall BASE_REF=브랜치명으로 기준을 바꿀 수 있습니다.

• Rule 6 : 1 Tab == 4 space, 즉 들여쓰기는 반드시 공백문자 4개로 해야합니다.

C++

• Rule 7 : 입출력은 C++ stream을 이용해야 합니다. ios::sync_with_stdio(false); cin.tie(nullptr);이 main 함수 안에 맨 첫줄에 있어야 합니다. endl 대신 '\n'을 써야합니다.
• Rule 8 : #define, typedef는 typedef long long ll; 또는 #define ll long long만 허용됩니다.
• Rule 9 : 논리 연산자인 and, or인 경우는 반드시 &&, || 로 사용해야 합니다.
• Rule 10 : 반드시 실수 연산을 해야하는 경우는 float보단 double로 사용해주세요. 이 외에는 반드시 정수에서 연산을 해주세요.
• Rule 11 : queue, priority_queue, stack, list 등과 같은 자료구조는 STL을 이용해주세요.
• Rule 12 : 문자열은 반드시 char*대신 string을 이용해주세요.
• Rule 13 : goto문을 쓰지 말아주세요.

권장 - 수정할 사항이 있으면 제가 직접 수정을 할 수 있습니다. 수정을 할 게 있다면 제 닉네임을 Co-Author에 추가합니다.

Python

• Rule 14 : (백준 문제 한정) 입력시 해당 코드 처럼 input 함수를 만들어 입력을 받아야 합니다.

Java

• Rule 15 : (백준 문제 한정) 해당 코드 처럼 FastReader Class를 이용해서 입력을 받아야 합니다.

공통

• Rule 16 : 변수와 함수의 이름은 어느 정도 의미하는 바를 드러내면서도 코드가 간결하도록 최대 10 글자 이내로 해주세요.
  hap, gop, gaesan와 같은 변수명이나 함수명은 사용하지 말아주세요.
• Rule 17 : 너무 많은 중첩 if문을 피해주세요.
• Rule 18 : 불필요한 연산이 없도록 최대한 정리를 해주세요.
• Rule 19 : 소스코드 일부에 어떤 코드인지 간단한 주석처리를 해주시면 감사하겠습니다. 다른 분들이 보실 때 코드만 볼 경우 이해가 안되는 경우가 있습니다.